- Wednesday, October 29, 2014

release-team@conference.openafs.org

Wednesday, October 29, 2014< ^ >

Room Configuration

Room Occupants

GMT+0
[08:00:22] shadow@gmail.com/barnowlE5B64A04 leaves the room
[08:00:30] shadow@gmail.com/barnowlE5B64A04 joins the room
[08:04:25] shadow@gmail.com/barnowlE5B64A04 leaves the room
[08:04:34] shadow@gmail.com/barnowlE5B64A04 joins the room
[09:58:34] wiesand joins the room
[13:57:33] kaduk joins the room
[14:01:04] meffie joins the room
[14:02:31] <kaduk> ${timeofday}
[14:05:16] <kaduk> I wonder if this will make wiesand's client make noise.
[14:06:40] <kaduk> So, peeking at the agenda, gerrit 11549 and 11550
[14:07:41] <Jeffrey Altman> hello
[14:07:53] <kaduk> I think the cherry-picks are both straightforward, so they should be okay for 1.6.11
[14:07:56] <Jeffrey Altman> rather distracted this morning
[14:08:45] <kaduk> That's at least 2/5, then...
[14:08:56] <meffie> i wonder if wiesand is on standard time now.
[14:09:05] deason joins the room
[14:09:39] <wiesand> I am, but that's not it
[14:09:45] <wiesand> give me a moment, sorry
[14:11:05] <kaduk> Also RT #131780, "getcwd".
Andrew posted a patch to gerrit; Anders is trying it out on the scripts.mit.edu machines.
[14:11:29] <kaduk> I don't remember seeing any getcwd issues since then, but it's only been a day or so.
[14:11:56] <kaduk> (Andrew's patch is gerrit 11559)
[14:19:17] <kaduk> It is ... something, that the quickstart guide has a disclaimer that it's currently being updated for openafs 1.4.10, so I just have to chanage the '4' to a '6'.
[14:20:50] <wiesand> Here I am. My apologies.
[14:20:55] <kaduk> To answer Stephan's question from the agenda, not having 11558 would cause a merge conflict when trying to cherry-pick 11559.
[14:21:07] <meffie> kaduk: i recently had to setup a 1.6.9 based test cell from scratch, i put my notes on the wiki.openafs.org.
[14:21:26] <kaduk> It's also slightly more correct, but probably not related to the core issues with 'getcwd'.
[14:21:54] <kaduk> meffie: I think I saw those go by in the commit log; I also updated some instructions on the freebsd wiki, so we should have a good base to go by, just need to get the actual changes in :)
[14:22:54] <meffie> let me know if i lied about anything. i also updated the gentoo wiki, as it was very very out of date (still has kaserver instructions)
[14:22:57] <kaduk> So, Stephan, do you want to hear more about the linux compat patches and/or getcwd?
[14:23:28] <wiesand> If there actually is more to hear, sure.
[14:24:05] <kaduk> I don't think I have anything.
[14:24:22] <kaduk> Probably the linux-compat patches should get another +1 and then be merged.
[14:24:33] <wiesand> But if 11558/9 is believed to solve it and Anders is testing, that's not so bad for now.
[14:25:26] <wiesand> I'll ask Marc by pm for Linux 1.8 news.
[14:25:27] <Jeffrey Altman> for Linux 3.18 there are changes required.
[14:25:35] <wiesand> 3.18, yes.
[14:25:56] <Jeffrey Altman> Marc is not ready to push changes to openafs
[14:26:17] <wiesand> Bad news. Any ETA?
[14:26:45] <Jeffrey Altman> no.
[14:26:55] <kaduk> Also, thank you for snagging the yosemite patch from RT and proxying it to gerrit.
[14:27:02] <wiesand> If not, we probably shouldn't block on it for the time being.
[14:27:21] <wiesand> I had time to kill this morning.
[14:27:39] <wiesand> Rare occasion...
[14:27:47] <kaduk> :)
[14:28:13] <wiesand> I hope that's material for 1.6.11 - it doesn't look dangerous at all.
[14:28:17] <kaduk> I've slowly been free time to forward-port the GSS patchset for openssh; I know the feeling
[14:28:57] <wiesand> Thanks for the +1s on the Linux 3.17 changes.
[14:29:07] <kaduk> You're welcome
[14:30:27] <wiesand> Should we strive for a pre1 soon, with the 3.17 changes, Andrew's fakestat fix, Yosemite, 11538 and very little else?
[14:30:27] <kaduk> If we can't talk about linux 3.18 stuff yet, should we move on to those RT tickets you mentioned?
[14:30:55] <wiesand> Sure, if there's input on the RT tickets, let's talk about them.
[14:31:19] <kaduk> No objection here to the pre1 plan; I'm not sure what else we would want to put in 1.6.11 anyway.
[14:31:30] <wiesand> Linux 3.18 ...
[14:31:50] <kaduk> oh, right, that.  But, no new features or anything that people want to get in.
[14:32:13] <kaduk> Well, the first RT ticket was the OS X bits, so if those look okay and get reviewed they should be fine; new OS version support is usually not very invasive.
[14:32:22] <wiesand> I think we should defer features to 1.6.12.
[14:32:37] <wiesand> +1
[14:32:45] <kaduk> Hmm, I didn't actually review 11538.  I guess I only reviewed the master version of that change, whoops.
[14:33:13] <kaduk> I don't think RT 131943 is a blocker; we've had that behavior for a long long time.
[14:33:30] <wiesand> 1.6.10+11538 is going into production at a serious site.
[14:33:35] <kaduk> I just happened to notice it when I was looking at systemd integration for debian.
[14:33:40] <kaduk> Yay!
[14:34:55] <kaduk> For RT 131940, I don't think we can do very much without more information from the submitter.
(Andrew, what do you think?)
[14:36:39] <wiesand> The one I considered a potential blocker is 131934 (not 43).
[14:36:44] <deason> well, he needs help interpreting; it's not just waiting for him
[14:36:50] <deason> but no, I don't consider that a blocker
[14:37:12] <wiesand> 40 or 43?
[14:37:22] <wiesand> er, 40 or 34 ?
[14:37:37] <deason> er, that comment was for 940
[14:38:02] <kaduk> Oh, I misread, sorry.
[14:39:08] <kaduk> Also I missed that 131934 did have an fstrace log attached.
Has anyone gotten a chance to look at it yet?
[14:41:04] <wiesand> If it's EL7 clients only, that could be handled alongside Linux 3.18 in a 1.6.11.1 release.
[14:41:58] <kaduk> It's unclear that we should assume it's EL7 clients only.  I guess we do know that EL7 has a patched kernel, so it's plausible, at least.
[14:43:43] <wiesand> "We can't replicate this with the same data file, writing to the same
server, on a RHEL6 1.6.9 client."
[14:43:59] <wiesand> So, probably, "large EL7 clients" only.
[14:44:14] <kaduk> Okay.
[14:45:11] <wiesand> Can someone poke him about the outcome of the last tests?
[14:47:03] <kaduk> Andrew, do you want it?  I guess I could.
[14:47:13] <wiesand> We shouldn't block on it IMHO. At least not pre1.
[14:47:31] <kaduk> Sure.
[14:47:34] <wiesand> But more info would still be good.
[14:47:35] meffie leaves the room
[14:47:38] meffie joins the room
[14:47:41] <kaduk> So, what *is* pre1 blocking on, the? :)
[14:47:51] <wiesand> Review.
[14:47:58] <kaduk> testing and merging for the fakestat fixes?
[14:49:00] <wiesand> And that, yes.
[14:49:13] <kaduk> Okay.
[14:49:44] <wiesand> And the Yosemite stuff.
[14:49:50] <kaduk> Prod people to review the particular changes in question as you see fit.
[14:49:54] <Jeffrey Altman> [131934]  Richard has been having client issues on the special hardware he is using for quite a while.  Going back at least as far as March when I was on site.
[14:50:33] <wiesand> Thanks. Still ugly, but makes it even less a blocker.
[14:50:45] <wiesand> Ben: will do ;-)
[14:51:16] <wiesand> On to 1.8? Ben, want to take the chair?
[14:51:33] <deason> (I'll be looking at it when I can; it's been on the todo pile)
[14:51:46] <kaduk> The host-to-zero stuff has +1s from Jeff and me, IIRC.
[14:52:28] <kaduk> Hmm, apparently I had bad wiki syntax at some point.
[14:53:55] <kaduk> We don't have anything else concrete on the list of "things to do prior to branching" once that gets merged.
[14:54:23] <Jeffrey Altman> just review what is in gerrit
[14:54:35] <shadow@gmail.com/barnowlE5B64A04> i will try to find some time to review what is in gerrit
[14:54:42] <kaduk> I had that down as pre-release but not necessarily blocking the branch
[14:55:18] <kaduk> I guess we can also re-ask folks here what testing of master (clients?) we've done recently.  I think we had a decent mix of linuxen, but didn't take notes the last time we asked.
[14:55:20] <Jeffrey Altman> I still do not believe there is any benefit to branching until we are ready to pre1
[14:56:17] <kaduk> Well, what do you consider necessary for a pre1?  The review of what's in gerrit?
[14:57:24] <kaduk> (The list of things "to be done before release" also includes documentation updates (KeyFileExt and converting keys from 1.6 to 1.8 format in particular), investigate volume header update issues, investigate whether vos release -stayup should be removed, and investigate "lockless path through d_revalidate" for potential issues.)
[14:58:49] <Jeffrey Altman> As an alternative to review what is in gerrit I believe it is fine to request patch authors to review their own submissions and raise their voice if there is any of their work they want in 1.8
[14:59:21] <Jeffrey Altman> I think vos release -stayup should be pulled before pre1
[15:00:10] <Jeffrey Altman> documentation KeyFileExt is certainly required before pre1
[15:01:09] <Jeffrey Altman> volume header update issues (if any) should preferably be addressed before we ask anyone to test with live data
[15:01:37] <Jeffrey Altman> d_revalidate could (in my opinion) be addressed after pre1 if necessary
[15:02:36] <kaduk> On the "review changes in gerrit" front, is there a way to get gerrit to give a list of such changes sorted by something that doesn't change when updates are pushed and comments are made?
[15:03:14] <Jeffrey Altman> Not that I am aware of through the web interface
[15:03:46] <kaduk> There's always the "new browser window with one tab per change" option...
[15:04:18] <deason> not via web, but you can get it via text
[15:04:46] <wiesand> I've missed that option too.
[15:04:51] <deason> the 'gerrit-not-reviewed' script I put in tools or whatever gives you an interface that can do that
[15:07:06] <kaduk> okay, thanks
[15:07:16] <wiesand> Can someone translate "vos release -stayup", "d_revalidate" and "volume header update issues" for me?
[15:07:29] <wiesand> Into something like RT tickets, gerrit changes, commits etc?
[15:08:20] <deason> for d_revalidate, you can use gerrit 3298 as an identifier for it; I just don't think it's safe
[15:08:41] <kaduk> I believe "vos release -stayup" is actually -stayonline, aka gerrit 6254
[15:08:54] <Jeffrey Altman> "vos release -stayup" would be reverting commit 13a4f2b18bb84d05773529a794371d29f64570ab
[15:09:41] <meffie> i think mark vitale has some notes for -stayup/-stayonline, he's back from traveling, i'll see if i can get his notes.
[15:10:11] <kaduk> IIRC, there are multiple gerrit items from Hans-Werner Paulsen relating to the volume header issues, e.g. 11468
[15:10:27] <Jeffrey Altman> 11468 requires jhutz review
[15:10:36] <kaduk> and 11432, it looks like is the other one from him
[15:10:41] <Jeffrey Altman> same
[15:10:54] <kaduk> I'll try to add that to my list of things to prod jhutz about...
[15:11:30] <wiesand> Thanks, and sorry for being dumb.
[15:11:57] <wiesand> Some of these are present in 1.6 though. Why do they have to be sorted out before branching?
[15:12:57] <kaduk> (which ones are present in 1.6?)
[15:13:01] <Jeffrey Altman> There are two underlying issues that need to be addressed there.   First, administrative changes to the volume such as quotas which are reflected in volume dumps do not currently change the volume header updateDate.   As a result they can be lost when incremental dumps are used since there is no indication that a change occurred.
[15:14:28] <wiesand> -stayonline is present (unless it was reverted)
[15:14:48] <Jeffrey Altman> The second is which dates which be used in the dump header for each type of volume.   At the present time in OpenAFS it is only safe to make backups from .backup volumes and not from a RW directly or from a temporary clone.
[15:18:48] <wiesand> But is master different in this respect from 1.6 and 1.4?
[15:21:19] <Jeffrey Altman> No.  In my opinion, fixing it is a major behavior change and that should certainly occur at the beginning of a new series.   If it is also pulled into 1.6 I will support it but I would also appreciate the opinion of someone that objects because it changes the meaning of a data header.
[15:22:11] <wiesand> Ok, thanks.
[15:22:26] <Jeffrey Altman> vos release -stayonline was pulled onto 1.6 after branching.  It is in my opinion too fragile for production use as it can leave temporary clones around that cannot be cleaned up automatically.   AFS3 Vol RPCs do not provide a method of querying volservers for volumes by name and it is not possible to guarantee that cloneIds will be reused consistently.  This can produce hard to diagnose outages if stray roclones fill up the on disk header preventing the creation of new temporary clones for the volume group.
[15:23:09] <wiesand> Shouldn't we pull it from both branches then?
[15:24:02] <wiesand> If the volume header changes haven't been merged by X-mas 2015, still no 1.8 branch?
[15:24:12] <kaduk> The argument that it is too large a behavior change to be done on a stable release branch also applies in this case.
[15:24:39] <kaduk> (I mean, it could potentially be overridden, but there is a barrier to surpass.)
[15:24:50] <Jeffrey Altman> I believe that vos release -stayonline should be pulled from 1.6 as well.  I have said that previously
[15:25:40] <wiesand> If we can pull it mid-series, why not after 1.8pre1?
[15:25:52] <Jeffrey Altman> the volume dump times changes from Hans are blocked on jhutz because he has said that he wants to analyze the impact of the changes before they are committed.
[15:26:53] <Jeffrey Altman> For 1.6 pulling -stayonline requires maintaining the command line parsing.  I do not believe that is required for 1.8
[15:28:27] <wiesand> Ok. Enough to write up today.
[15:28:36] <wiesand> Anything else?
[15:28:56] <Jeffrey Altman> It is also fine for it to remain in 1.6 or in 1.8 if Mark Vitale has fixes.
[15:29:15] <kaduk> I don't have any other 1.8 topics that need discussion.
[15:29:23] <kaduk> Just things that need doing :)
[15:29:24] <meffie> ok, i'll ping Mark
[15:29:49] <wiesand> Thanks.
[15:29:49] <Jeffrey Altman> thanks everyone
[15:30:22] <wiesand> I still have a 75% draft of last week's minutes in my draft folder.
[15:30:22] <kaduk> Thanks
[15:30:57] <wiesand> The phone rang. When that call was done, it was too late. Next time I had a chance to look at it, everything was obsolete.
[15:31:06] <wiesand> I'll try to do better this time.
[15:31:29] <wiesand> BTW volunteers welcome...
[15:38:59] <wiesand> I have to leave. Thanks a lot everyone!
[15:39:03] wiesand leaves the room
[16:32:35] meffie leaves the room
[16:32:36] meffie joins the room
[17:57:12] meffie leaves the room
[21:18:42] kaduk leaves the room
[23:44:05] deason leaves the room