- Friday, February 9, 2018

release-team@conference.openafs.org

Friday, February 9, 2018< ^ >

Room Configuration

Room Occupants

GMT+0
[03:21:28] mvita leaves the room
[03:21:28] mvita joins the room
[04:47:17] mvita leaves the room
[08:26:49] mvita joins the room
[08:26:50] kaduk@jabber.openafs.org/barnowl leaves the room
[08:31:17] kaduk@jabber.openafs.org/barnowl joins the room
[10:46:26] mvita leaves the room
[11:59:24] Marcio Barbosa joins the room
[13:41:57] meffie joins the room
[14:00:55] <meffie> good morning
[14:01:11] <kaduk@jabber.openafs.org/barnowl> greetings
[14:01:42] <meffie> sorry the NEWS wasnt finished yet. it will be done today.
[14:02:25] <kaduk@jabber.openafs.org/barnowl> No worries; I'm still merging the accumulated changes anyway
[14:02:30] <meffie> just wanted to get that off my chest before we started.
[14:02:47] <kaduk@jabber.openafs.org/barnowl> Even having the pullups all ready is a big help
[14:03:16] <meffie> i feel we have a clumsy workflow with gerrit :)
[14:03:25] <kaduk@jabber.openafs.org/barnowl> Did Stephan say he was not planning to be here, or should we wait a bit?
[14:03:36] <kaduk@jabber.openafs.org/barnowl> You think we should switch to git-review? ;)
[14:04:07] <meffie> heh. no, i've tried that one once, lets stick with gerrit.
[14:04:28] <meffie> i dont recall a message from stephan.
[14:05:11] wiesand joins the room
[14:05:13] mvita joins the room
[14:05:21] <meffie> welcome
[14:05:30] <mvita> present
[14:05:32] <wiesand> Sor\ry for being late
[14:05:38] <mvita> sorry I'm late too
[14:05:48] <mvita> no heat here, and little sleep
[14:05:55] <kaduk@jabber.openafs.org/barnowl> (I had to look up the time and make sure I was going to be here -- still
getting used to the friday slog)
[14:06:00] <kaduk@jabber.openafs.org/barnowl> no heat?!
[14:06:38] <mvita> :-(
[14:06:51] <meffie> unplanned winter camping.
[14:06:55] <mvita> furnace guy is coming soon
[14:07:00] <wiesand> ouch
[14:07:14] <kaduk@jabber.openafs.org/barnowl> ouch indeed
[14:07:23] <kaduk@jabber.openafs.org/barnowl> hopefully your pipes are not at risk of freezing
[14:07:49] <wiesand> if they do, just tear down the house…
[14:07:56] <mvita> it runs if I reset it every few minutes
[14:08:12] <mvita> so I was up late doing that to prevent frozen pipes in the garage
[14:08:18] <mvita> the rest of the house should be okay
[14:08:33] <kaduk@jabber.openafs.org/barnowl> Wow.  You had a rough night.
[14:08:48] <wiesand> really sorry to hear hat
[14:09:01] <mvita> thanks, let's move on
[14:09:25] <wiesand> did you by chance take your laptop to the garage and look into the RHEL7.5beta kernel issues?
[14:09:44] <mvita> I did that earlier in the week
[14:09:51] <kaduk@jabber.openafs.org/barnowl> building kernels is like a space heater, right?
[14:09:54] <mvita> your config log diffs are the smoking gun
[14:10:05] <mvita> but I need the RH source to go further
[14:10:18] <meffie> mvita: i should bring the sparc boxes to your house now, for the heat.
[14:10:24] <mvita> certainly some API we use in afs_linux_readdir is busted, but I could not figure out what
[14:10:58] <mvita> I reviewed all the changes in mainline (master) Linux to see what RH might have (selectively) pulled and came up empty
[14:11:04] <wiesand> I'm afraid the minor release betas aren't public
[14:11:07] <meffie> wiesand: we are also reaching out to some of our redhat contacts for info
[14:11:18] <mvita> we have contacted RH to try to get some source access.
[14:11:27] <wiesand> good!
[14:11:45] <kaduk@jabber.openafs.org/barnowl> I'm confused how not making source for minor release betas public is
consistent with the GPL, but there is really no point in us discussing
that line of reasoning here
[14:12:01] <kaduk@jabber.openafs.org/barnowl> I hope the RH outreach will be fruitful
[14:12:15] <meffie> me too. on both counts.
[14:12:19] <mvita> me too - I don't want to wait for CentOS again.
[14:12:52] <mvita> (btw, there is no CentOS 7.5 yet, I checked)
[14:13:31] <wiesand> The source is GPL. You just violate your contract w/ RH if you pass it on…
[14:14:30] <mvita> oh, the first problems reported by Kodiak (hang/crash at init) was figured out by Ben, so thank you for that!
[14:14:53] <mvita> RH upgrade from 7.4 + systemd = sadness
[14:15:02] <kaduk@jabber.openafs.org/barnowl> Well, only partially ... someone else will need to figure out why the
unit file allows the second start on upgrade
[14:15:16] <wiesand> I think this wasn't the first report of systemd attempting to restart an already running client. Something may be wrong with our unit file
[14:15:17] <mvita> so the only remaining issue is the ENOTDIR, which at least 3 sites have duplicated
[14:15:48] <meffie> wiesand: it's not, but we thought it was fixed, if i recall.
[14:15:58] <mvita> I would try to duplicate it myself but I think it's fruitless to do so without the source
[14:16:01] <wiesand> Yes, and given the changes in fs.h and configure results, these seem plausible
[14:16:47] <wiesand> Have you checked out the developer program?
[14:17:13] <wiesand> Everything for free, as long as it's used for development on RHEL only.
[14:17:14] <mvita> I will resort to that if our current outreach is not helpful
[14:17:36] <kaduk@jabber.openafs.org/barnowl> In the debian openafs-client-precheck I check for a running afsd and
refuse to start.  I guess I don't check for a module already loaded,
though, so maybe I would be susceptible to a similar issue
[14:18:07] <wiesand> The SL packaging does this too ;-)
[14:18:35] <mvita> There were hints in Kodiak's logs that the problem was related to our afs_pagecopy background stuff
[14:20:23] <mvita> it is started when the kmod is loaded and stopped when unloaded.  afsd does nothing with it.
[14:20:32] <meffie> wiesand: yeah, we will probably be looking into the developer program, depending on what our contacts say.
[14:21:06] <meffie> sna works with redhat on non-openafs stuff too, so it's a matter of coordinating.
[14:21:47] <wiesand> btw, are we worried about http://lkml.iu.edu/hypermail/linux/kernel/1801.3/03340.html ?
[14:22:15] <mvita> I also saw in the RH 7.5 release notes that they now support loading kmods from anywhere, not just the usual path.
[14:22:31] <mvita> so perhaps there is an interaction there as well with packaging and systemd
[14:23:36] <kaduk@jabber.openafs.org/barnowl> We don't appear to touch i_version directly
[14:23:43] <wiesand> Frankly, I haven't understood that part. You could always "insmod /whatever/…/*.ko
[14:23:59] <wiesand> Ben: thanks
[14:25:02] <mvita> agreed, it looks like i_version is not relevant for us
[14:25:07] <wiesand> Anyway, on to 1.6.23pre1…
[14:25:34] <wiesand> The significant part is that ubik stack I believe.
[14:26:16] <wiesand> And two of those chnages have yet to be merged on 1.8.x, thus pre1 is blocked on this at the very least.
[14:26:47] <wiesand> 12886, 12896
[14:27:00] <kaduk@jabber.openafs.org/barnowl> I skipped "only relabel db if epoch is sane" this morning :(
I forgot where we update the global
[14:27:07] <Marcio Barbosa> I believe Andrew will be reviewing these changes soon
[14:28:53] <wiesand> The problem is that the first quarter of the Linux [4.15,4.16) interval has passed and we still have some way to go before 1.6.23pre1 can be issued.
[14:29:11] <wiesand> If it takes too long, the whole stack will have to wait for 1.6.24.
[14:31:15] <meffie> ah, it's my fault for taking too long getting the 1.8.x gerrits submitted. sorry.
[14:31:22] <wiesand> I rebased 12328 once more, but if it doesn't get any attention now I'll abandon it.
[14:32:27] <meffie> yeah, maybe it's better to just leave that change for 1.8.x?
[14:32:27] <wiesand> 12864 is the one Jeffrey brought up -  needs review
[14:33:27] <wiesand> at least 12818 should probably go into pre1 too
[14:34:42] <meffie> oh, yes, that would be helpful.
[14:34:51] <wiesand> 12684..7 are candidates too… they have a +1 from Mike (the author), but some more would help
[14:35:17] <wiesand> 12667 is on my list as well
[14:36:48] <meffie> oh, 12667 was a fun bug.
[14:37:27] <wiesand> and many of the other changes open on 1.8.x (FBSD, Solrias stuff, CellServDB update, …), though many of those wouldn't even warrant issuing a pre2 IMO snd thus aren't quite as urgent
[14:37:28] <mvita> heh, debugging that AFSDB stuff is so much fun
[14:37:40] <mvita> fvvo "fun"
[14:37:56] <kaduk@jabber.openafs.org/barnowl> yeah, certain versions of "fun" only...
[14:38:38] <wiesand> So much for the 1.6.23 items.
[14:38:46] <mvita> that's a lot !
[14:38:59] <kaduk@jabber.openafs.org/barnowl> Indeed!
[14:39:26] <wiesand> If the ubik stack is to make it, I want a pre1 with it *really*soon*now*.
[14:39:38] <meffie> i'll try to do a better summary in the notes of the items for 1.6.23.
[14:41:28] <wiesand> Obviously we can drop whatever the team considers unimportant/unfit for the 1.6 series.
[14:41:35] <wiesand> Or postpone
[14:42:06] <wiesand> Though postponing just makes things worse
[14:42:27] <wiesand> On to 1.8?
[14:42:38] <kaduk@jabber.openafs.org/barnowl> Okay
[14:43:02] <kaduk@jabber.openafs.org/barnowl> Mike made pullups for basically everything we want in pre5, but I didn't
start looking at merging things until last night/this morning
[14:43:32] <kaduk@jabber.openafs.org/barnowl> But I think the plan is still to merge what's in gerrit plus
NEWS+versions and make that pre5
[14:44:22] <meffie> i'll finished the NEWS after my morning meetings.
[14:46:27] <wiesand> I pulled up "Replace <rpc/types.h> with <rx/xdr.h>", mentioned on the mailing list, as well. Another one for 1.6.23, right?
[14:46:35] <kaduk@jabber.openafs.org/barnowl> Yup
[14:46:47] <kaduk@jabber.openafs.org/barnowl> gotta stay ahead of the bleeding edge glibc
[14:47:54] <meffie> ben, for the ones i submitted to gerrit, i set the topic to 1.8.0pre5, for all of them, regardless of the type of change. is that ok?
[14:48:02] <kaduk@jabber.openafs.org/barnowl> I think so
[14:48:22] <meffie> also, i used get review to push them. it seems like a very nice tool.
[14:48:50] <kaduk@jabber.openafs.org/barnowl> cool
[14:49:20] <meffie> also, i did not push them as a branch, but "one at a time", except for the ctf stuff which needed the new acinclude refactor.
[14:49:47] <kaduk@jabber.openafs.org/barnowl> Ah, that explains the way they were showing up in gerrit's "same topic"
change list.
[14:49:50] <meffie> it would be *a lot* easier to just do a rebase and push the whole branch, but i guess we dont like that ?
[14:50:18] <kaduk@jabber.openafs.org/barnowl> That's not exactly wrong
[14:50:38] <kaduk@jabber.openafs.org/barnowl> If they're all definitely going to go in, having them on a branch is
easier
[14:50:54] <kaduk@jabber.openafs.org/barnowl> And even if we skip one, it's only a problem if it's a "merge conflict"
in gerrit's mind
[14:50:58] <meffie> that would save the order.
[14:51:17] <kaduk@jabber.openafs.org/barnowl> right
[14:51:26] <meffie> ok, great!
[14:52:02] <meffie> the only thing is then to set the "cherry-picked from" line in the commit message. rebase will not do that, as far as i know.
[14:52:26] <wiesand> As long as they don't touch the same file(s), gerrit allows merging the in any order, no matter whether they're marked for the same topic or not, I believe.
[14:52:38] <kaduk@jabber.openafs.org/barnowl> You can cherry-pick a range
[14:52:50] <kaduk@jabber.openafs.org/barnowl> ==wiesand
[14:52:51] <meffie> hmm,
[14:53:08] <meffie> oh, gerrit cherry-pick
[14:53:11] <kaduk@jabber.openafs.org/barnowl> and if there's a conflict, you do a 'git add && git cherry-pick
--continue' same as rebase.  Well, at least in modern-ish versions of
git
[14:53:37] <kaduk@jabber.openafs.org/barnowl> I was not trying to refer to a gerrit cherry-pick, but a git one, if
that's what you're thinking
[14:53:48] <meffie> ok
[14:53:54] <wiesand> but that will require you to add the (cherry-picked from line) manually
[14:54:44] <wiesand> The ubik changes open on 1.6 are a nice example how not to do it ;-)
[14:55:09] <kaduk@jabber.openafs.org/barnowl> No, you don't need to add the (cherry-picked from line) manually
[14:55:30] <meffie> currently, my workflow is to use something like: git cherry-pick -x $(git rev-list --grep="$subject" master)
[14:55:36] <meffie> for each commit
[14:55:36] <kaduk@jabber.openafs.org/barnowl> git checkout -b backports origin/openafs-stable-1_8_x
git cherry-pick -x origin/master~6..origin/master
profit
[14:55:40] <wiesand> Then my git is too old
[14:56:34] <meffie> oh, ranges!
[14:57:28] <wiesand> On to master?
[14:57:46] <kaduk@jabber.openafs.org/barnowl> Sure
[14:58:09] <meffie> thanks for the git tips! :)
[14:58:12] <kaduk@jabber.openafs.org/barnowl> I looked at the arm64_linux26 stuff a bit more and am basically ready to
merge it but had a couple of minor questions
[14:59:16] <kaduk@jabber.openafs.org/barnowl> in 11940, do we think we care enough about two-spaces-after-full-stop
(and consistency with the other files) to re-roll the change?
[14:59:40] <kaduk@jabber.openafs.org/barnowl> I'm also curious if anyone has a reason to/to not keep the arm64_linux2
sysname in favor of just arm64_linux26
[15:00:19] <kaduk@jabber.openafs.org/barnowl> Also there is perhaps some more style nitpicking on 11937
[15:01:53] <meffie> i suppose *_linux2 is just historical baggage?
[15:02:22] <kaduk@jabber.openafs.org/barnowl> In more substantive matters, Andrew reminder me of the question he
raised in the rxgk reviews, namely of whether it makes sense to
implement the CLEAR and AUTH levels at all, especially with no way to
configure what mode is enabled.
I think it's pretty clear that it doesn't make sense to have the code
with no way to enable it other than recompiling, so it's a question of
do we remove the code or do we add a knob to allow the less-protected
data.
[15:02:40] <kaduk@jabber.openafs.org/barnowl> > just historical baggage
That's my assumption, but I don't have any actual data to back that up.
[15:04:01] <mvita> re: rxgk clear, auth - thinking
[15:04:04] <kaduk@jabber.openafs.org/barnowl> I could perhaps imagine some case where regulatory requirements require
that the data be visible in transit but the tamper-resistance of the
AUTH level is useful, but that's a big stretch to imagine.  I have a
less good sense for whether there will be performance concerns that make
people want to drop to clear, though.
[15:05:18] <wiesand> Re arm*_linux2: There is no merged code actually supporting it, right?
[15:05:48] <wiesand> Re clear/auth: a knob makes sense IMO…
[15:05:55] <kaduk@jabber.openafs.org/barnowl> Well, plain arm_linux2 is in-tree already
[15:06:05] <mvita> that's how I"m leaning as well - a knob
[15:06:55] <meffie> maybe a knob would be useful for testing/debugging scenarios?
[15:07:34] <wiesand> Hmm, interesting mail from Hartmut on -devel 2 minutes ago
[15:07:40] <kaduk@jabber.openafs.org/barnowl> (comments are most appropriate on 10571 for this question, I think.)
[15:08:04] <kaduk@jabber.openafs.org/barnowl> Hasn't gotten here yet :9
[15:08:50] <wiesand> In openafs 1.8 in ubik/remote.c you will end up with a database labeled "0.0" in
the case we found out that the host the new database should come from is not the
one we have the connection to. Keep the old version in tversion and epoch to
restore it if actually we didn't get a new database.
--- remote.c.orig       2018-01-03 06:56:08.000000000 +0100
+++ remote.c    2018-01-20 17:52:58.222611247 +0100
@@ -460,6 +460,8 @@
    /* send the file back to the requester */
    dbase = ubik_dbase;
+    memcpy(&tversion, &dbase->version, sizeof(struct ubik_version));
+    epoch = tversion.epoch;    /* Keep th current version to restore it later */
    pbuffer[0] = '\0';
    if ((code = ubik_CheckAuth(rxcall))) {
@@ -498,7 +500,7 @@
    offset = 0;
    UBIK_VERSION_LOCK;
-    epoch = tversion.epoch = 0;                /* start off by labelling
in-transit db as invalid */
+    tversion.epoch = 0;                /* start off by labelling in-transit db
as invalid */
    (*dbase->setlabel) (dbase, file, &tversion);       /* setlabel does sync */
    snprintf(pbuffer, sizeof(pbuffer), "%s.DB%s%d.TMP",
            ubik_dbase->pathName, (file<0)?"SYS":"",
[15:09:19] <kaduk@jabber.openafs.org/barnowl> fun
[15:09:33] <wiesand> Marcio?…
[15:11:10] <Marcio Barbosa> looking
[15:15:14] <kaduk@jabber.openafs.org/barnowl> Hmm, Mark, should 12795 be abandoned?
[15:15:49] <meffie> (fyi, i turn in to a pumpkin in 15 minutes)
[15:17:23] <kaduk@jabber.openafs.org/barnowl> I think we're winding down anyway
[15:17:41] <wiesand> re "abandon 12795": probably
[15:17:52] <mvita> huh, I never realized we merged a different gerrit.  abandoning...
[15:18:04] <kaduk@jabber.openafs.org/barnowl> I think the last thing I had was that clear/auth thing.
And if no one else opines about the style issues in arm64_linux26 I'll
probably just merge as-is
[15:18:25] <wiesand> Ben: if there is an issue in 1.8.0pre4, and it's not addressed in the open ubik changes, that's failry serious IMHO
[15:18:53] <kaduk@jabber.openafs.org/barnowl> wiesand: I agree
[15:20:01] <kaduk@jabber.openafs.org/barnowl> (I am still failing to see this mail from Hartmut either in my inbox or
the archives)
[15:20:35] <meffie> well, it's good to get this report *before* pre5.
[15:21:09] <kaduk@jabber.openafs.org/barnowl> True
[15:21:23] <kaduk@jabber.openafs.org/barnowl> I don't know that we need to try and debug things live during the
meeting, though
[15:21:38] <meffie> yes, i'll take this offline with Marcio.
[15:22:08] <wiesand> Ben: just bounced it to you. What I pasted above was the full content though.
[15:22:54] <meffie> before i disappear, can i say some things about the buildbot?
[15:23:04] <kaduk@jabber.openafs.org/barnowl> Yes, please
[15:23:08] <wiesand> Ok, there's an open issue. There's plenty to do for everyone even w/o that.
[15:23:14] <wiesand> Mike: please
[15:24:07] <meffie> ok, sorry for the errors you saw this week for the linux-daily/linux-rc builders. that was tooling issue that was exposed by an upgraded on the builders; it's been fixed.
[15:25:04] <meffie> 2. andrew has made some arm64 kvms for me, and i'll be adding them to the buildbot; sles and ubuntu. they will be nightlie not gerrtis (too slow)
[15:25:19] <meffie> that's all i got for now. thanks.
[15:25:20] <wiesand> Thanks for fixing it! Figuring out that it's probably something like this wasn't too hard.
[15:25:45] <kaduk@jabber.openafs.org/barnowl> Yes, thanks for working on that
[15:26:23] <wiesand> Those daily/rc builders turned out to be *a*lot* more useful than I thought!
[15:26:44] <meffie> me too. thanks to mark for making me do it. :)
[15:27:08] <mvita> <scowls>
[15:27:30] <meffie> i should document them on wiki.openafs.org
[15:28:18] <wiesand> Let's adjourn for today. Thanks a lot everyone!
[15:28:19] <meffie> motion to adjurn?
[15:28:25] <meffie> thanks!
[15:28:34] <mvita> okay, thanks
[15:28:38] <kaduk@jabber.openafs.org/barnowl> Sure, let's adjourn.
Thanks everyone!
[15:42:51] <Marcio Barbosa> I still have to take a closer look but this ubik bug seems to be present on 1.6. Also, it looks like that this bug is not related with recent changes.
[15:53:25] <Marcio Barbosa> His patch seems to be the way to go.
[16:27:09] <meffie> thanks marcio
[16:27:34] <meffie> i wonder if it's just easier to trigger on 1.8.x?
[16:27:48] meffie leaves the room
[17:56:38] meffie joins the room
[18:10:55] <Marcio Barbosa> > i wonder if it's just easier to trigger on 1.8.x?
i don’t think so. we just have to hit one of those ‘goto failed’ from SDISK_SendFile. those failures are not very common but possible.
[18:15:03] <Marcio Barbosa> and even if we have one of those failures, the version of the database of the remote in question will not be equal to 0 for a long time (since the sync-site re-sends the database if SDISK_SendFile fails).
[19:37:26] meffie leaves the room
[20:06:38] meffie joins the room
[21:18:32] Marcio Barbosa leaves the room
[21:37:59] meffie leaves the room
[22:03:56] wiesand leaves the room