- Wednesday, January 14, 2015

release-team@conference.openafs.org

Wednesday, January 14, 2015< ^ >

Room Configuration

Room Occupants

GMT+0
[00:32:59] shadow@gmail.com/barnowlE5B64A04 leaves the room
[00:33:10] shadow@gmail.com/barnowlE5B64A04 joins the room
[05:20:05] Jeffrey Altman leaves the room
[05:29:59] Jeffrey Altman joins the room
[05:36:59] Jeffrey Altman leaves the room
[05:42:47] Jeffrey Altman joins the room
[06:46:51] shadow@gmail.com/barnowlE5B64A04 joins the room
[06:47:50] shadow@gmail.com/barnowlE5B64A04 leaves the room
[06:55:38] shadow@gmail.com/barnowlE5B64A04 leaves the room
[06:55:46] shadow@gmail.com/barnowlE5B64A04 joins the room
[07:12:33] shadow@gmail.com/barnowlE5B64A04 leaves the room
[07:12:42] shadow@gmail.com/barnowlE5B64A04 joins the room
[12:29:48] shadow@gmail.com/barnowlE5B64A04 leaves the room
[12:29:57] shadow@gmail.com/barnowlE5B64A04 joins the room
[14:23:33] meffie joins the room
[14:58:07] Marc Dionne joins the room
[14:59:02] shadow joins the room
[15:00:39] wiesand joins the room
[15:01:05] <wiesand> Hi
[15:01:17] <shadow@gmail.com/barnowlE5B64A04> hi
[15:02:17] <Marc Dionne> good morning/afternoon
[15:02:38] <wiesand> good morning
[15:02:52] <wiesand> Sorry again for the late invitation/agenda.
[15:04:53] <meffie> morning
[15:05:18] <wiesand> Thanks for the review. The showstopper currently is probably the configure switch for the d_splice_alias fix.
[15:05:28] kaduk joins the room
[15:06:00] <wiesand> Marc, any more bad Linux news?
[15:06:14] <Marc Dionne> no, steady on that front
[15:06:19] <kaduk> I guess I can bump the d_splice_alias configure switch to the tip of my queue.
[15:06:44] <kaduk> (Otherwise I would be looking at switching the vcache and dcache hash tables to jenkins hash.)
[15:06:48] <Marc Dionne> with what's in gerrit, should still be good with current 3.19-rc4+
[15:08:16] <wiesand> Thanks.
[15:08:40] <wiesand> There seem to be differing opinions on 11616.
[15:09:36] <kaduk> I think that "put an assert in on master but just silently succeed on 1.6" is going to carry the day.
[15:09:48] <shadow> that's my take
[15:10:18] <wiesand> “don’t assert on 1.6” would be my preference too.
[15:10:21] <kaduk> I have not explicitly commented to that effect, but that's my preference.
[15:10:43] <wiesand> But it’s 1.6-only, and different solutions are under discussion  for master, right?
[15:10:49] <kaduk> Right.
[15:11:30] <wiesand> Has one of the alternative solutions been merged on master yet?
[15:11:54] <kaduk> nope
[15:12:32] <kaduk> 11615 is the most likely (in my non-expert opinion), but Andrew is still uncertain of its correctness.
My feelings are mostly based on Chas's incomplete recollection
[15:12:47] <wiesand> I’m not sure we should merge a 1.6-only fix for an issue not yet addressed on master in any way...
[15:13:49] <wiesand> Unless the gatekeepers are explicitly comfortable with that, at least.
[15:14:55] <shadow> well, we can put in an assert quickly as it should be easily reviewable
[15:15:37] <shadow> give me a moment; i was updating 10004
[15:15:51] <kaduk> This is true.
It would cause conflicts for 11615 to deal with, but that's also manageable.
[15:16:07] <kaduk> > 10004
Yay
[15:17:52] <shadow> or, you know, bombs away
[15:23:23] <kaduk> So, what's next on the agenda?
[15:23:49] <shadow> there. have 11669
[15:29:40] Marc Dionne joins the room
[15:34:01] <shadow> i don't know if we care about 10713. deason's -1 seems spurious but marc's looks legit (configure test that never does anything)
[15:34:01] Marc Dionne leaves the room
[15:34:32] <kaduk> Yeah.
[15:34:58] <kaduk> It's also hard to get super-super-excited about a single linux version that (apparently) people aren't using anymore, judging by the lack of outcry.
[15:34:59] <shadow> (sorry, just trolling backwards to see what might be mergeable and especially what might be wanted for pullups)
[15:35:35] <shadow> speaking of deason, i feel like i haven't seen him around in a while. of course, i'm one to talk.
[15:35:51] <kaduk> He's been busy
[15:36:19] <kaduk> I sent him unicast mail (not from gerrit) to ask him to revisit his -1s on a few changes (that I thought were simple but apparently were not).
[15:37:33] <kaduk> He hopes to return to his backlog within a week.
[15:38:01] <kaduk> Are you pushing a rebase of 11606 or should I?
[15:39:03] <meffie> oh, i can rebase it.
[15:40:09] <kaduk> Hmm, I bet this "mandatory configure option" for 11643 will cause buildbot to fail to configure it.
[15:40:37] <wiesand> good point...
[15:43:18] wiesand joins the room
[15:43:37] <shadow> brb: biology break
[15:43:38] wiesand leaves the room
[15:44:28] <wiesand> one more of those us tv memes?
[15:45:30] <Jeffrey Altman> "brb" == be right back
"biology break" == going to the bathroom
[15:45:50] <wiesand> ah ;-) no, google just kicked me out
[15:47:22] <shadow> ok
[15:47:35] <wiesand> Ok, seems we’re on track, except for that configure switch.
[15:48:17] <kaduk> working on it...
[15:49:49] <wiesand> Thanks. Still, that point regarding a mandatory switch and buildbot seems valid. I guess it can be handled with per builder configuration?
[15:50:02] <shadow> which means we gotta kick the master
[15:50:04] <kaduk> Marc, is linux commit 51486b900ee the one we care about for the d_splice_alias stuff?
[15:50:30] <kaduk> I'm thinking about evil tricks to conditionalize on building under buildbot or not.
[15:50:43] <shadow> —enable-developer or something
[15:50:51] <shadow> nd then always have buildbot define it?
[15:50:56] <kaduk> For now, I'll submit something with a default so that buildbot can have its day.
[15:51:10] <wiesand> Good.
[15:51:16] <shadow> yes, buildbot sure is a dog
[15:51:41] <Jeffrey Altman> apparently we can use "buildbot reconfig" instead of restarting the buildbot master to force a new configuration
[15:52:01] <Marc Dionne> ben, yes 51486b900ee is the commit we care about (or its equivalent in the stable trees)
[15:52:18] <kaduk> thanks
[15:52:19] <meffie> yes, i use reconfig quite a lot on our internal buildbot.
[15:54:07] <meffie> also, you can use build variables to dynamically set stuff like config options.
[15:55:28] <meffie> (sorry, it's called "build properties")
[15:57:45] <wiesand> Sadly, I’ll have to leave in 5 minutes. 1.6.11pre2 seems straightforward now (11616 ok to merge after 11669 was, but remove the “FIXES” and add a reference to the 11669 commit?).
[15:58:10] <shadow@gmail.com/barnowlE5B64A04> sounds ok
[15:58:40] <kaduk> Anything else you want to cover before you go?
[15:58:46] <kaduk> I guess we can still talk about 1.8 after you leave...
[15:59:06] <wiesand> Yes, that’s what I thought.
[15:59:21] <shadow@gmail.com/barnowlE5B64A04> smart choice :)
[15:59:48] <wiesand> I don’t have anything else for today, unless one of you has?
[15:59:53] <kaduk> Though, mostly I just want to talk about the email threads I split out.
[16:00:28] <wiesand> Fine, go ahead. I have to run, sorry. Thanks a lot everyone!
[16:00:31] wiesand leaves the room
[16:01:27] <kaduk> Any thoughts from the gatekeepers about the vos changeaddrs vs mh entries analysis/options?
[16:03:45] <shadow@gmail.com/barnowlE5B64A04> i read that and my brain hurt yesterday. lemme go look again
[16:03:52] <kaduk> Sorry :(
[16:04:25] <kaduk> The summary is that 11606 and 11638 are client-side changes that are hopefully uncontroversial, and we should choose one of 11604, 11639, and 11640; Mike and I prefer 11639
[16:05:20] <shadow@gmail.com/barnowlE5B64A04> jeff needs to look at 11638 and decide if his -1 holds
[16:06:06] <kaduk> Ah, right, thanks for mentioning that.
[16:08:51] <shadow> of those, i'd take 11639
[16:09:00] <shadow> so marked.
[16:11:36] <Jeffrey Altman> 11639 is the option I requested.   it is still the version I prefer
[16:11:55] <kaduk> I think I was uncertain what behavior you had requested.
[16:11:55] shadow@gmail.com/barnowlE5B64A04 leaves the room
[16:11:57] <Jeffrey Altman> I have removed my -1 from 11638.
[16:11:57] shadow@gmail.com/barnowlE5B64A04 joins the room
[16:12:04] <kaduk> It's good that we all agree on it, though :)
[16:12:08] <kaduk> Thank you.
[16:12:22] <Jeffrey Altman> well, we don't know that jhutz and chaskiel agree on it
[16:12:28] <kaduk> For the volume header timestamp stuff, if I have summarized things correctly, we should just take gerrit 11468 and 11627, and hold off on anything else for now.
[16:12:50] <kaduk> If they care, they can reply to the email thread...
[16:13:18] <kaduk> Is there agreement/disagreement with that summary of the volume header timestamp issues?
[16:15:27] <shadow@gmail.com/barnowlE5B64A04> sounds acceptable
[16:15:52] <Jeffrey Altman> I have +1 11468 and 11627
[16:17:02] <kaduk> Yay.
[16:17:49] <kaduk> re 8841 (FD_SET size shenanigans), I think we can consider this not a release blocker.
[16:18:16] <kaduk> (this is subject: "asserting on out-of-bounds FD_SET calls" in my mail last week)
[16:18:28] <kaduk> Any comments there?
[16:21:23] <shadow> not a blocker. i think it needs more research
[16:21:37] <kaduk> *nods*
[16:22:11] <kaduk> Mike, do you want to say anything about log rotation?  I guess you did -1 3347 with a note about updates in progress, so maybe we should just wait and see.
[16:25:06] <kaduk> Alternately, any responses to the comments I sent about OSD or volunteers to talk to Hartmut?
[16:25:07] <meffie> yeah, updates in progress. basically, i propose we check the size before renaming.
[16:25:31] <Jeffrey Altman> I'm the deliverer of bad news.
[16:27:07] <kaduk> Okay, then.
[16:27:19] <kaduk> Other things still on my/someone's plate:<more>
[16:27:55] <kaduk> for 10227, we probably should do as Jeff suggests and find all call sites prior to VInitAttachVolumes.
[16:29:02] <kaduk> 11349 and related about encrypting more things by default.
I'm not sure if Nathaniel is planning on updating 11349 anytime soon (maybe I should ask).
[16:30:32] <kaduk> You probably saw the conversion to jenkins hash in src/vol patches; I also started looking at doing the same for the vcache and dcache hash tables.  It looks like Arne's numbers will take another meg or so of kernel memory, but I don't think I find that especially problematic.
[16:30:56] <kaduk> And we also wanted someone (TM) to implement Simon's scheme in 2591.
[16:30:59] <Jeffrey Altman> go for it
[16:31:13] <Jeffrey Altman> going back to 11349
[16:31:46] <kaduk> But I think that's it for things requiring development effort that we might want in 1.8; the rest is just code review and fallout from the same.
[16:32:30] <shadow> i'd be fine with 2591 and then simon's idea.
[16:33:26] <Jeffrey Altman> The reason I suggested to Nathaniel that he encrypt the traffic for volserver to volserver operations is because he was seeing random data corruption during volume replication and moves and without the rxkad checksums there is no method of catching truncated data packets.
[16:33:59] <kaduk> If anyone has a linux system handy and feels like checking that 11643 patch 5 actually makes you pass --enable or --disable, that would be nice.
[16:34:25] <kaduk> I am on OS X at the moment...
[16:34:41] <kaduk> Ah, that's a good point re checksums
[16:34:45] <Jeffrey Altman> Yesterday I spoke with one of our customers that is seeing random corruption of data during volume moves.
[16:35:14] <kaduk> But IIRC rxkad_auth is just as slow as rxkad_crypt, right?
[16:35:47] <Jeffrey Altman> rxkad_auth is not quite as slow as rxkad_crypto
[16:35:57] <Jeffrey Altman> but still pretty slow
[16:36:20] <kaduk> Ah.
[16:36:56] <Jeffrey Altman> unfortunately, the rx header does not have a length field.   The assumption is the data length is whatever is left in the udp packet after the rx header is subtracted.   That was a poor choice
[16:37:57] <kaduk> Indeed.
[16:37:58] <Jeffrey Altman> I have no additional details at the moment
[16:38:17] <kaduk> "Clearly, we should make an rx_mostlynull security class that just adds a length field"
[16:39:21] <Jeffrey Altman> nah, just reimplement AFS using REST APIs
[16:39:40] <kaduk> Anyway, I don't think I have anything else I want to discuss today.
Anyone else?
[16:39:41] <meffie> websockets
[16:40:37] <shadow> i got nothing
[16:41:16] <Jeffrey Altman> the only other thing I wanted the group to considered is whether all of the discussion that is being sent to release-team is really semi-private or not.   Most discussion of gerrit tickets I believe should really go to openafs-devel;
[16:41:35] <kaduk> That is plausible.
[16:42:01] <kaduk> I'll try to keep that in mind for the future.
[16:42:06] <Jeffrey Altman> thanks.
[16:42:12] <kaduk> Do you think it's worth bouncing my threads from last week to -devel as well?
[16:42:45] <Jeffrey Altman> I doubt it makes a huge difference but contributors such as Nathaniel and Chas Williams are not on the release-team list
[16:42:55] <Jeffrey Altman> and the archives are not public
[16:43:20] <Jeffrey Altman> It probably is worth bouncing the threads
[16:43:46] <meffie> moving development discussions to devel lists and rooms makes sense.
[16:43:53] <kaduk> Okay.
[16:44:35] <Jeffrey Altman> with that I will say so long
[16:44:45] <kaduk> Thanks, everybody
[16:45:56] meffie leaves the room
[17:38:22] Marc Dionne leaves the room
[17:55:28] shadow leaves the room
[18:28:13] <jhutz@jis.mit.edu/owl> > people aren't using anymore,single linux version
A range of versions, actually
> people aren't using anymore
I don't think you can assume that.  all you know is that no one (else) has
complained about not being able to build 1.6 against those versions.  Some
of us have to support old things for a long time.  Most people are probably
sticking with 1.4 there, but I absolutely do not think it is OK for OpenAFS
to tell such people they have no choice but to stick with 1.4 and at the
same time say 1.4 is dead and everyone has to move to 1.6.
[18:31:03] <jhutz@jis.mit.edu/owl> > well, we don't know that jhutz and chaskiel agree on it
I already said that I'm happy as long as there is some interface for admins
to manipulate addresses in mh entries.  It doesn't have to be vos
changeaddr
[18:33:33] <kaduk> You trimmed the "(apparently)".  I am happy to put in effort to support things that people are actually using, but don't feel a need to spend effort to support something that is not being used.  If you want to use it (i.e., are still using it), the onus is on you to keep mentioning it, which you have just done.
[18:35:55] <jhutz@jis.mit.edu/owl> > 8841 ... not a release blocker.
That's probably best.  There still seems to be a lot of confusion about
what FD_SETSIZE is and what it isn't.  To be clear, it's the size of the
user-mode data structure, and on most (all?) platforms, you can change it
as long as you do so early enough (before relevant headers are included).
It doesn't necessarily relate to what you can pass to select (that's why
select takes a count parameter!), and it doesn't relate to the maximum
possible filehandle.
[18:37:16] <jhutz@jis.mit.edu/owl> The problem we had on some Solaris versions was that we'd raise the maximum
number of file descriptors without increasing FD_SETSIZE.
[18:38:22] <kaduk> It might be worth noting that in gerrit.
[22:45:12] kaduk leaves the room