- Wednesday, August 2, 2017

release-team@conference.openafs.org

Wednesday, August 2, 2017< ^ >

Room Configuration

Room Occupants

GMT+0
[00:39:15] kadukoafs@gmail.com/barnowl35A66400 leaves the room
[00:41:21] kadukoafs@gmail.com/barnowl772461F2 joins the room
[12:58:00] meffie joins the room
[14:58:11] jhg joins the room
[15:00:16] <kadukoafs@gmail.com/barnowl772461F2> Good morning (I say, before wiesand steps in)
[15:00:39] <mvita> Good day, sir.
[15:00:40] <meffie> good morning.
[15:01:16] wiesand joins the room
[15:01:41] <wiesand> good evening
[15:01:48] <kadukoafs@gmail.com/barnowl772461F2> Hi Stephan
[15:03:01] <wiesand> There was quite a bit of churn in gerrit last week, and I haven't been able to pay close attention
[15:03:23] <wiesand> I believe most of that was 1.8 related
[15:03:38] <kadukoafs@gmail.com/barnowl772461F2> I think so, yes.
[15:03:56] <wiesand> And the ubik fixes targeted at 1.6.x too haven't been merged yet, right? (not all of them at least)
[15:04:17] <kadukoafs@gmail.com/barnowl772461F2> I tried to get jhutz to look at the latest 12609 but he didn't get
time yet
[15:04:33] <kadukoafs@gmail.com/barnowl772461F2> The other two I'm happy with, but was waiting to merge them in a
group.
[15:04:49] <wiesand> Yes, that's fine of course.
[15:05:13] <meffie> thanks Ben
[15:05:26] <wiesand> I think this means a change of plan, since we'll not have an early pre1 with the ubik fixes for the next 1.6 release.
[15:06:12] <meffie> what is our target for early pre1?
[15:06:16] <wiesand> Let's plan for 1.6.21.1 with Linux 4.13 + possibly other client stuff, and shift the ubik ones to 1.6.22?
[15:06:37] <meffie> that sounds good.
[15:06:43] <kadukoafs@gmail.com/barnowl772461F2> Well, I was toying with merging the ubik stuff today without jhutz
input, for 1.8 purposes, but I don't know if you have different
criteria for 1.6.22pre1 than I do for 1.8.0pre2
[15:08:26] <wiesand> Mike: I don't have a hard and fast rule in mind, but Linux 4.13 is at rc3, so about 4 weeks from GA while not everything is on master yet, and that rules out an "early pre1" IMO.
[15:08:55] <meffie> yes, thanks.
[15:10:10] <meffie> as far we know, we dont need any other changes for 4.13 yet.
[15:10:20] <wiesand> Ben: I had hoped for 22pre1 within a week or two after the 21 release.
[15:10:41] <kadukoafs@gmail.com/barnowl772461F2> Right, I remember that now.
:(
[15:11:15] <wiesand> MIke: thanks. But we do need the changes we have to cope with 4.13, so we can't let the next release slip for long.
[15:11:50] <wiesand> Ben: no worries, we'll have an early 22pre *after* 21.1 then ;-)
[15:12:44] <wiesand> And I think that concludes the 1.6 topic for today?
[15:13:14] <kadukoafs@gmail.com/barnowl772461F2> I don't have anything for 1.6, not that I usually do, of course.
[15:13:33] <wiesand> On to 1.8 then?
[15:13:38] <mvita> oui
[15:13:51] <kadukoafs@gmail.com/barnowl772461F2> I sent mail with some 1.8 status updates, but the short form is that
we should be able to branch after 12609 gets "sufficient" review.
[15:14:12] <meffie> yay
[15:14:17] <kadukoafs@gmail.com/barnowl772461F2> So, I guess I can ask if anyone here has looked at patchset 5 or 6 and
thought about it very much.
[15:14:39] <meffie> mark knows ubik more than i do.
[15:15:10] <mvita> last ps I looked at was 2
[15:15:15] <mvita> I will take a look later today
[15:15:22] <kadukoafs@gmail.com/barnowl772461F2> Thanks
[15:15:24] <meffie> thanks mvita
[15:15:42] <kadukoafs@gmail.com/barnowl772461F2> The main thing I'm unconfident about at this point is under what
circumstances it's okay for the beacon thread to take the DB lock.
[15:15:59] <mvita> okay
[15:16:09] <kadukoafs@gmail.com/barnowl772461F2> The existing code has comments that imply it's okay to do so on
not-the-sync-site
[15:16:50] <kadukoafs@gmail.com/barnowl772461F2> If that's the case, then ps 6 should be safe and we should roll it
out.
[15:18:23] <kadukoafs@gmail.com/barnowl772461F2> In non-ubik news, I have commits staged to remove src/rxgk and
src/mcas, and bump version numbers to 1.8.0pre2
[15:18:43] <meffie> excellent
[15:18:51] <mvita> except for rxgk
[15:18:54] <kadukoafs@gmail.com/barnowl772461F2> Also a NEWS entry for the ubik changes, which I guess I could push now
and get review on.
[15:19:12] <kadukoafs@gmail.com/barnowl772461F2> Well, those are staged locally because they only go on the 1.8 branch.
[15:19:13] <meffie> well, those will go back in after the branch, right.
[15:19:32] <meffie> er, right?
[15:19:57] <kadukoafs@gmail.com/barnowl772461F2> My plan has them staying continuously on master, but 1.8-only changes
to remove them.
[15:20:14] <meffie> yes, that was my understanding.
[15:21:06] <meffie> that is, rxgk stays on master, but not 1.8.x
[15:21:14] <kadukoafs@gmail.com/barnowl772461F2> I also took a look at the configure defaults again, and the only one I
would think about changing was enable-namei-fileserver. The
implementation is a bit complicated, with configure controlling
whether we build a vfsck, but all (?) existing param.h files directing
the use of AFS_NAMEI_ENV anyway.
[15:21:17] <kadukoafs@gmail.com/barnowl772461F2> Right.
[15:21:41] <kadukoafs@gmail.com/barnowl772461F2> So I don't really feel much need to change things for 1.8, but would
consider removing inode fileserver support post-1.8
[15:22:06] <meffie> seems sensible.
[15:22:14] <mvita> agreed
[15:22:15] <kadukoafs@gmail.com/barnowl772461F2> I also see some more documentation stuff from Mike; thanks for that
[15:22:20] <wiesand> +1
[15:22:47] <wiesand> on both accounts
[15:22:47] <meffie> i'm not sure if i wrote rx-debug.txt or koyla did :)
[15:23:00] <meffie> i found a newer version that i know i wrote.
[15:23:39] <kadukoafs@gmail.com/barnowl772461F2> Oh, right, and looking in gerrit I am reminded that I pushed 12668
[15:23:49] <kadukoafs@gmail.com/barnowl772461F2> To default unix clients to crypt mode.
[15:24:16] <kadukoafs@gmail.com/barnowl772461F2> I would feel a little uncomfortable doing that for 1.8 after
1.8.0pre2, so would prefer to get a decision now-ish.
[15:25:05] <kadukoafs@gmail.com/barnowl772461F2> And if Joe is around, there's a question left on 12651 before it can
go in, though generally it looks good.
[15:26:02] <meffie> well, i'm not sure it's a good idea to default to crypt mode. it kills performance, and rxkad isn't strong anyway. so we are slow by default.
[15:26:17] <wiesand> Re "default to crypt mode": now or never IMHO
[15:26:22] <meffie> "slow and weak by default"
[15:26:41] <kadukoafs@gmail.com/barnowl772461F2> I mean, Debian does it already, FreeBSD does.
[15:26:55] <kadukoafs@gmail.com/barnowl772461F2> I guess I didn't look at the red hat unit file in the tree, though.
[15:26:56] <meffie> yes
[15:27:06] <mvita> > "kills performance"
[15:27:14] <mvita> even on modern hardware?
[15:27:41] <meffie> well, that's been my experience with it.
[15:27:45] <kadukoafs@gmail.com/barnowl772461F2> Well, "clearly we can make the change in pre2 and the beta testers
will let us know", right?
[15:27:48] <wiesand> I was going to ask "Does it really kill performance"?
[15:28:38] <mvita> well - I imagine decryption happens in the listener - so single threaded there
[15:28:43] <wiesand> (I honestly don't know)
[15:28:43] <meffie> wouldn't make sense to enable it by default with rxgk?
[15:29:22] <jhg> Ben, I'll take a look
[15:30:00] <kadukoafs@gmail.com/barnowl772461F2> rxgk's crypto ought to be faster on modern harware, and integrity-only
might actually be noticably faster than crypt+integreity
[15:30:35] <meffie> yes, and crypto that is strong enough to be useful :)
[15:31:55] <kadukoafs@gmail.com/barnowl772461F2> Thanks, jhg
[15:32:15] <wiesand> I don't have a strong opinion. It's runtime configurable...
[15:32:17] <meffie> if you make it on by default now, i'm afraid we will just teach people to turn it off.
[15:32:45] <meffie> then, when rxgk is ready, they'll have to retrained
[15:33:00] <kadukoafs@gmail.com/barnowl772461F2> Maybe I can try to run some tests and get some numbers
[15:33:22] <meffie> just my opinion tho, i have no facts to back it up.
[15:33:33] <wiesand> Those number would help
[15:33:52] <kadukoafs@gmail.com/barnowl772461F2> It's a fair question to raise, and we should probably get some dat
before deciding, yes.
[15:34:43] <meffie> sounds good.
[15:34:56] <wiesand> I tend to agree with Mike. If we make it the default now, and we receive reports like "1.8.0pre2 performance sucks", would we ask folks to try without encryption?
[15:35:07] <kadukoafs@gmail.com/barnowl772461F2> I don't think I have anything else. If Mark is happy with 12609, then
I think we can move forward with pre2
[15:35:29] <kadukoafs@gmail.com/barnowl772461F2> modulo the crypt question, of course
[15:35:35] <mvita> I've read it all, I have a few things I need to check before +1
[15:36:14] <kadukoafs@gmail.com/barnowl772461F2> Sure.
[15:36:23] <kadukoafs@gmail.com/barnowl772461F2> I didn't expect a full ubik code review during the meeting!
[15:36:42] <mvita> oh, I know… I just wanted to let you know I started sooner than I planned
[15:37:02] <kadukoafs@gmail.com/barnowl772461F2> Great. Thanks again!
[15:37:33] <wiesand> Let's adjourn then?
[15:37:35] <kadukoafs@gmail.com/barnowl772461F2> Any other topics for today?
[15:37:44] <kadukoafs@gmail.com/barnowl772461F2> Ah, you beat me to it :)
[15:38:08] <mvita> none here
[15:38:10] <wiesand> Sorry. 1.8 part… your call :-)
[15:38:29] <kadukoafs@gmail.com/barnowl772461F2> Nah, it's fine -- "great minds think alike"
[15:38:40] <wiesand> [flattered]
[15:39:02] <meffie> have a good day. thanks everyone.
[15:39:18] <kadukoafs@gmail.com/barnowl772461F2> thanks everyone!
[15:39:19] <wiesand> Thanks a lot everyone!
[15:39:22] meffie leaves the room
[15:39:24] wiesand leaves the room
[15:39:27] <mvita> bye
[15:39:29] <jhg> o/
[16:20:10] mvita leaves the room
[16:52:56] meffie joins the room
[16:56:39] meffie leaves the room
[17:14:34] mvita joins the room
[18:14:06] meffie joins the room
[20:24:17] meffie leaves the room
[20:40:22] <kadukoafs@gmail.com/barnowl772461F2> Thanks, mvita!
[20:40:37] <mvita> you're welcome
[21:14:07] meffie joins the room