- Wednesday, March 4, 2015

release-team@conference.openafs.org

Wednesday, March 4, 2015< ^ >

Room Configuration

Room Occupants

GMT+0
[11:47:24] shadow@gmail.com/barnowlE5B64A04 joins the room
[11:54:25] shadow@gmail.com/barnowlE5B64A04 leaves the room
[13:30:25] wiesand joins the room
[13:34:52] meffie joins the room
[14:42:57] kaduk joins the room
[14:59:50] <wiesand> Hi
[15:00:00] <kaduk> $timeofday
[15:00:17] <meffie> hi
[15:01:19] <wiesand> Jeffrey already covered Linux 4.0 in his mail: no news (= good news)
[15:01:20] <meffie> congratulations on the release
[15:01:33] <wiesand> Ah, thanks ;-)
[15:01:57] <kaduk> Getting things out the door always feels good :)
[15:02:06] <kaduk> Of course, now I have to get it into Debian, and FreeBSD...
[15:02:09] <meffie> yes.
[15:02:37] <wiesand> Ubuntu is having lots of trouble lately.
[15:03:12] <wiesand> So, it does feel good. But after the release is before the release. Let’s try to deliver 1.6.12 more timely.
[15:03:55] <wiesand> As I see it, this means mainly Linux 4.0 and ubik db, and little else.
[15:04:11] <meffie> +1
[15:04:40] <kaduk> And probably something to appease the freebsd 10.1 builder, if we can figure that out quickly.
[15:04:48] <wiesand> A pre1 around 4.0rc4 should be doable.
[15:05:02] <kaduk> I'm surprised that the pullup of the "use bsd.kmod.mk" commit failed, and it failed in a very curious way.
[15:05:21] <wiesand> It wasn’t exactly a clean cherry pick.
[15:05:37] <wiesand> I’m not too surprised ;-) I may simply have gotten it wrong.
[15:06:58] <kaduk> I hadn't bothered submitting a cherry-pick of it, myself, because there was some concern that there were too many/too invasive changes to non-FreeBSD-specific bits.
[15:08:05] <wiesand> It touches nothing but MakefileProto.FBSD.in
[15:08:48] <wiesand> But it may have prerequisites that are invasive.
[15:09:05] <kaduk> Well, in any case, doing something for fbsd101 is on my radar.
Yeah, there were probably some invasive prerequisites ... but those could potentially be reworked.
[15:09:47] <wiesand> The other changes in that stack just quiet some warnings. Most seem fairly harmless.
[15:10:07] <wiesand> But it’s good to know you have this on your list.
[15:10:18] <kaduk> Yeah, the ones you pushed looked fine; I am going from super-old memory here, so it's vague.
[15:10:54] <wiesand> And thanks for pulling up the ubik changes.
[15:11:04] <kaduk> I think Daria also said she would look at the ubik pullups; hopefully we can get some reviews in on those this week.
[15:11:35] <wiesand> That would be great.
[15:11:50] <wiesand> Still, the Linux 4.0 changes need some review (and testing if possible) too.
[15:12:13] <wiesand> And that’s all we absolutely must have in place for 1.6.12 :)
[15:12:37] <wiesand> We may include a few trivial things just to clean out the queue.
[15:12:48] <kaduk> Sure.
[15:13:02] <wiesand> Is there anything non-trivial anyone would like to push for?
[15:13:33] <meffie> not that i know of.
[15:13:40] <kaduk> I have been focusing on 1.8, so nothing here.
[15:13:49] <wiesand> Good :)
[15:14:21] <wiesand> Regarding RT #132020: that’s pretty infrequent.
[15:15:02] <wiesand> Still annoying though. Are the negative counters (and average RTT time) in the rxdebug output harmless?
[15:15:56] <kaduk> I don't know, offhand.
[15:16:16] <wiesand> NB the cache is ~700 MB, I wrote 128 shortly after an “fs flushall”.
[15:16:34] <wiesand> So it’s unlikely that this explains the partial writes and the slowness.
[15:17:06] <wiesand> And these “m.Length was ... now ...” look like something is ligged that’s not expected to happen?
[15:17:21] <wiesand> I failed to locate the code emitting this though.
[15:17:52] <kaduk> It's where it says: src/afs/VNOPs/afs_vnop_write.c:583, I expect
[15:18:18] <wiesand> That’s where I looked ;-) Found nothing. Some macro maybe
[15:18:25] <kaduk> which is some afs_trace4 macro or something
[15:18:26] <kaduk> right
[15:19:35] <wiesand> But it’s certainly no showstopper. There’s no reproducer, and the affected client had to be rebooted.
[15:19:37] <kaduk> See CM_TRACE_SETLENGTH in src/afs/afs_trace.et for the string
[15:20:45] <kaduk> Do we want to try to talk about getcwd, or should we move on to 1.8?
[15:21:34] <wiesand> Getcwd won’t make 1.6.12. And discussing it w/o Andrew seems kind of pointless.
[15:21:46] <kaduk> Yeah..
[15:21:53] <wiesand> So, fine with moving on to 1.8.
[15:22:18] <kaduk> We merged some of the ubik and vos changeaddrs stuff -- the list is shrinking!
[15:22:36] <meffie> yay!
[15:22:55] <kaduk> Well, don't cheer too hard -- you still have work to do, Mike :-P
[15:23:09] <meffie> ha
[15:23:24] <kaduk> But, I guess the ball is in our court for 11638 (re-review)
[15:23:27] <meffie> yes, i see a bunch of new reviews came in.
[15:23:52] <meffie> excellent comments. i will work on them this week.
[15:23:58] <kaduk> Review for 11769 and 11770 (my doc changes) would be nice, too.
I realized yesterday or the day before that I failed to verify that the new man page for KeyFileExt was actually getting installed, though.
[15:24:37] <kaduk> I have the shake-loose-vcaches work on my list of maybe-release-blockers
[15:24:49] <kaduk> So it would be nice if that could be on your list, Mike.
[15:25:05] <meffie> yes, i restarted looking at the shake harder patch.
[15:25:28] <kaduk> Cool, thank you.
[15:25:45] <meffie> the one that is in gerrit is actually working on  a largish set of machines, which are very sad without it.
[15:26:00] <kaduk> I will push an update to 9985 shortly (once it builds with all the now-unused variables after the latest edits)
[15:26:27] <kaduk> Oh, I'm sure it's still helpful in its current form; we can make it cleaner, though.
[15:26:51] <meffie> yes
[15:27:03] <kaduk> Regarding the jenkins hash conversions, Hans-Werner did some testing, which is reassuring.
[15:27:10] <meffie> i'm keen to see 9985 go in :)
[15:27:15] <kaduk> (11673, 11679)
[15:28:09] <kaduk> So once the jhash conversions get more review, they could probably go in as well.
[15:28:15] <meffie> also, again, should we be doing this sort of discussions in the other jabber room, for a wider audience?
[15:29:16] <kaduk> I think this kind may not need the wider audience.  But I also don't really care one way or the other.
[15:29:35] <kaduk> (New 9985 up)
[15:29:58] <wiesand> it’s not that much wider right now...
[15:30:07] <meffie> fair point.
[15:30:33] <kaduk> There was no objection on -info to axing linux 2.4 support; I guess I can put something together that does the bare-bones bits.  No need to go through the code and adjust all the AFS_LINUX2N_ENV conditionals all at once, I think.
[15:30:45] <kaduk> So that would let us get back to 6947 (new softsig)
[15:31:00] <meffie> also, no objections for the people i asked.
[15:31:20] <kaduk> But, I don't think 6947 has a current "owner" -- Simon submitted the original, and he doesn't seem to be putting much energy into pushing changes forward at the moment.
[15:31:59] <wiesand> Adopt it ;-)
[15:32:08] <kaduk> So, uh, "any volunteers (other than me)?"
[15:32:32] <kaduk> I know this is kind of a small crowd, and we all have other things on our plate; just wanted to mention it in case.
[15:32:47] <meffie> well, i can fix up the broken white space :)
[15:33:20] <kaduk> There also seemed to be support on -info for encrypt-by-default, which would require new development work.
[15:33:42] <kaduk> I'm not sure how long we should be willing to wait for that work to happen.
[15:34:20] <kaduk> And the release engineer in me is not very excited about shoving brand-new code into a release, since that has the potential for letting sloppy mistakes in.
[15:34:50] <meffie> that should not be a lot of time though, for encrypt-by-default? i might be able to get some time to do it.
[15:35:02] <meffie> (since we have customers that want it)
[15:35:09] <kaduk> Probably not that much time, yes.
[15:35:40] <kaduk> I'd want to spend time thinking about what the config file should look like, but once that's in place the rest of it should be fairly straightforward.
[15:35:53] <kaduk> So, we'll see what happens in the next couple weeks, I guess.
[15:35:54] <meffie> (or someone else at sna)
[15:36:10] <wiesand> I wouldn’t wait forever... the weak encryption is fairly easy to turn on.
[15:36:36] <kaduk> I'll mention 11691 again here (revamp linux file lock processing), but it looks like that's not going to make it into the release without someone stepping up to put a fair bit of energy in, and no one that I know of is complaining loudly for it.
[15:36:48] <kaduk> wiesand: well, that's not exactly true -- it requires source changes.
[15:37:02] <kaduk> for the server-to-server traffic, that is.
[15:37:09] <wiesand> I meant for a client admin ;-)
[15:37:15] <wiesand> Ah, true.
[15:37:39] <wiesand> 11691: if that won’t make it, how about 2591?
[15:38:03] <kaduk> That still requires someone putting the energy in to review it.
[15:38:05] <meffie> even so, for server to server, it is not difficult (if you just use the cipher we have now)
[15:38:48] <kaduk> Marc's review of 11691 (regarding the lock getting dropped) would seem to imply that something like the checking in 2591 will be needed, but reviewing this stuff takes energy.
[15:39:15] <kaduk> meffie: Yeah, it's a one-line patch if you know where to put it.
[15:40:23] <kaduk> (looking at the list of potential blockers) Hmm, I guess I owe an update for 7896, to factor out the prname length check.
[15:41:08] <kaduk> If Andrew were here, I might try to talk about 10789, but I don't have enough state on the various rx timeouts to have much to say.
[15:41:56] <kaduk> What do people think about having an "akeyconvert" to help with the 1.6-->1.8 upgrade (to one-shot convert rxkad.keytab to KeyFileExt)?
[15:42:31] <kaduk> It seems easier to tell people "run this one command" than "go mucking about with listing the keytab and running asetkey a bunch of times", and also gives a chance to enforce a couple sanity checks.
[15:44:02] <kaduk> On the other hand, it's a one-off utility that might only be used at upgrade time and which we'd have to support for an unknown period of time.
[15:44:48] <shadow@gmail.com/barnowlE5B64A04> one hopes once written you ate done
[15:44:53] <shadow@gmail.com/barnowlE5B64A04> "are" done
[15:45:06] <kaduk> Right.  "You're done until those pesky users come around asking for more features"
[15:46:07] <kaduk> I guess one potential stumbling block is that I currently use mergesort() from libc (OS X, BSD), and I'm not 100% sure that that routine is available everywhere.
[15:46:57] <kaduk> But, it would be possible to add a layer or two of glue and use qsort() instead, so that's not really a critical issue.
[15:47:38] <meffie> anything to make the upgrade smoother gets my vote
[15:48:24] <kaduk> Glancing over the outstanding changes in gerrit, I guess I didn't put the 'externalize-log-rotation' series on my list from two weeks ago; I should probably fix that, since that's one of those "disruptive changes to make at a major release boundary"
[15:49:33] <kaduk> Chas had the negative caching in afsconf_LookupServer patch (currently -1'd) ... any thoughts for or against putting that in 1.8, whether before release or after?
[15:51:15] <kaduk> I think I still owe an update for the ubuntu1404 support series
[15:51:40] <kaduk> It might be nice to get 10227 (prevent useless salvages when AFS config is invalid) in, but it needs review.
[15:52:23] <kaduk> There's a bunch of ~small bugfixes that can go it, but I don't see anything else particularly noteworthy.
[15:52:42] <kaduk> So, maybe we should call it for today and get to work ;)
[15:53:36] <wiesand> I’ll do the opposite :)
[15:54:22] <wiesand> Unless there’s anything else to discuss?
[15:54:38] <meffie> wiesand, are you on the security queue?
[15:54:49] <wiesand> No.
[15:55:03] <meffie> ok, thanks.
[15:55:16] <wiesand> Wait. I’m allowed to read tickets in the security queue in RT.
[15:55:23] <meffie> oh
[15:55:52] <wiesand> I don’t have the key though, so if tickets are encrypted that’s still a no.
[15:56:46] <kaduk> I usually send an empty mail to the queue to allocate a ticket, and then add correspondence via the web (over SSL).
[15:57:10] <meffie> ah, good idea.
[15:57:26] <kaduk> ... except when MIT's outgoing servers are blacklisted so that RT bounces my mail.
[15:57:35] <kaduk> Then I have to pester jhutz or somebody to manually create a ticket for me.
[15:58:18] <meffie> i hear there was gco 131878 reported as a possible security related issue.
[15:59:01] <kaduk> Well, I get EPERM, so I am no help there.
[15:59:35] <wiesand> Mike: yes, I’m aware of it.
[16:00:19] <meffie> ok, thanks
[16:00:39] <wiesand> I can’t help it though :-(
[16:01:11] <meffie> oh.
[16:01:44] <meffie> are we waiting for someone to submit a CVE?
[16:02:16] <wiesand> Obviously.
[16:02:55] <meffie> oh, ok.
[16:03:34] <wiesand> And then it’s a timing issue. 2 weeks...
[16:05:32] <meffie> ok, in the meantime, embargoed.
[16:08:00] <wiesand> Yeah. It’s not for me to decide how to handle such issues.
[16:08:51] <wiesand> So, sorry.
[16:09:08] <wiesand> Unless there’s anything else, I’d walk home now :)
[16:09:17] <meffie> nothing else. thank you.
[16:09:56] <kaduk> Nothing here.  Thank you.
[16:09:57] <wiesand> Thank you all! Please review the 4.0 and ubik stuff, and we might get out 1.6.12 in time for a change.
[16:10:03] <wiesand> Bye now.
[16:10:05] wiesand leaves the room
[16:17:08] meffie leaves the room
[21:36:51] kaduk leaves the room
[21:56:28] shadow@gmail.com/barnowlE5B64A04 leaves the room
[21:56:37] shadow@gmail.com/barnowlE5B64A04 joins the room