- Wednesday, August 9, 2017

release-team@conference.openafs.org

Wednesday, August 9, 2017< ^ >

Room Configuration

Room Occupants

GMT+0
[10:37:59] kadukoafs@gmail.com/barnowl772461F2 leaves the room
[10:38:11] kadukoafs@gmail.com/barnowl772461F2 joins the room
[12:05:01] meffie joins the room
[14:58:47] wiesand joins the room
[15:00:32] <meffie> good afternoon wiesand
[15:00:56] <kadukoafs@gmail.com/barnowl772461F2> Hi
[15:01:14] <mvita> hello
[15:03:39] <wiesand> Good morning USA
[15:04:14] <wiesand> Let's briefly cover the 1.6.x part...
[15:04:50] <meffie> looks like we are still ok for 4.13
[15:05:12] <wiesand> Plan is a 1.6.21.1 in time for Linux 4.13, and we seem to be good with -rc4 (with the "designated initializers" patch)
[15:05:28] <meffie> yes
[15:05:29] <wiesand> + maybe some more client stuff
[15:05:53] <wiesand> And I think that covers 1.6.x :)
[15:05:58] <meffie> yay
[15:06:09] <mvita> indeed
[15:06:11] <wiesand> for the time being...
[15:06:44] <kadukoafs@gmail.com/barnowl772461F2> is that my cue?
[15:06:47] <wiesand> Then let's have an early 1.6.22pre1 with the ubik changes & more.
[15:06:55] <wiesand> Ben: yes ;-)
[15:07:12] <kadukoafs@gmail.com/barnowl772461F2> Sorry again that it took so long to get hte ubik changes into master
[15:07:20] <wiesand> NP
[15:07:26] <kadukoafs@gmail.com/barnowl772461F2> Anyway, you probably saw the mail I sent to -devel about the new
branch
[15:07:28] <meffie> no worries
[15:07:37] <meffie> yay
[15:07:58] <wiesand> New branch before Xmas. Hooray ;-)
[15:08:05] <kadukoafs@gmail.com/barnowl772461F2> And I pushed a few commits targetting it, but (1) my first revision
shouldn't have built, which leads to (2) the buildbot config needs to
learn about it
[15:08:05] <meffie> heh
[15:08:19] <kadukoafs@gmail.com/barnowl772461F2> But AFAIK, the plan is to issue pre2 with just those three changes.
[15:08:54] <meffie> oh, the buildbot patches.. oops, i need to deploy those
[15:09:30] <kadukoafs@gmail.com/barnowl772461F2> No worries; I need to do some other stuff anyways
[15:09:35] <kadukoafs@gmail.com/barnowl772461F2> (FreeBSD and IETF)
[15:10:22] <kadukoafs@gmail.com/barnowl772461F2> I'm not sure that it's entirely clear how to proceed post-pre2, but
probably we can say that if it bakes for a month and nobody complains,
we should go ahead with a final release.
[15:10:47] <wiesand> What's blocking pre2?
[15:11:12] <kadukoafs@gmail.com/barnowl772461F2> gerrit reviews and buildbot verification
[15:11:33] <wiesand> the usual culprits...
[15:11:34] <meffie> ok, i'll get to the buildbot changes asap
[15:11:58] <kadukoafs@gmail.com/barnowl772461F2> Thanks meffie
[15:12:17] <kadukoafs@gmail.com/barnowl772461F2> So anyway, I don't know that I have a whole lot on 1.8 itself, per se.
[15:12:27] <kadukoafs@gmail.com/barnowl772461F2> It sounds like we've had a decent number of people testing already,
which is good.
[15:12:47] <kadukoafs@gmail.com/barnowl772461F2> Do we want to open up the floor for prioritization of post-1.8 topics?
[15:13:11] <meffie> i'm not ready to talk about that ;)
[15:13:54] <wiesand> Well I sure still want rxgk, and it should be P{1..10} IMHO
[15:14:01] <meffie> yes.
[15:14:04] <kadukoafs@gmail.com/barnowl772461F2> I had the displeasure of discovering that the tip of rxgk stuff in
gerrit does not match with any commits in my "local" (i.e., github)
development branch for rxgk.  The diff isn't too big, so I should be
able to figure out which bits I want, but it will be a little work.
[15:15:14] <kadukoafs@gmail.com/barnowl772461F2> It's probably a bit early to discuss some of the other items at the nd
of https://wiki.openafs.org/archive/OpenAFS18Notes/, I suppose (like
"rip out LWP")
[15:15:18] <kadukoafs@gmail.com/barnowl772461F2> But rxgk, yes.
[15:15:19] <meffie> i am going to be dusting off the ints to ipv4 structs conversion branches in my github.
[15:15:33] <kadukoafs@gmail.com/barnowl772461F2> And if there was any IPv6 WIP buried away, I suppose.
[15:15:35] <meffie> which are a prereq for ipv6
[15:16:19] <meffie> i also have a branch that rips put lwp from xstat/scout/afsmonitor, etc.
[15:16:30] <kadukoafs@gmail.com/barnowl772461F2> And we still have a big question mark in terms of new database
formats for rxgk support (and the related question of the logistics
for deploying a database format change).
[15:16:36] <meffie> *rips out
[15:16:39] <kadukoafs@gmail.com/barnowl772461F2> cool
[15:17:06] <kadukoafs@gmail.com/barnowl772461F2> It may be worth a note to -devel when starting such a thing, to
prevent duplicate effort.
[15:17:27] <wiesand> Is there absolutely no way around a new db format?
[15:17:34] <meffie> ok, good idea.
[15:18:25] <kadukoafs@gmail.com/barnowl772461F2> We need to record which fileservers are rxgk-capable, their
token-encrypting keys, etc.  We need more fields, definitely, but
presumably can do so in a backwards-compatible way.  (That is, one
that just extends the current format.)
[15:18:32] <mvita> ah
[15:19:22] <wiesand> pity
[15:19:24] <kadukoafs@gmail.com/barnowl772461F2> So, a strawman would be to have the new version of the software gain
an RPC that says "I know about these database formats", the sync site
can query everybody and make sure that they have a new enough
software, then either via RPC or DISK_write flip the switch to start
using the new format.
[15:19:32] <mvita> almost sounds like it could be a new DB
[15:19:52] <mvita> neither prdb nor vldb
[15:19:53] <kadukoafs@gmail.com/barnowl772461F2> Also another option, though multi-db support in a single process is
still lacking, IIRC.
[15:20:07] <kadukoafs@gmail.com/barnowl772461F2> And the specs have implicitly assumed it would be in the vldb
[15:20:25] <kadukoafs@gmail.com/barnowl772461F2> (Oh, and prdb "ought to" gain support for storing extended names,
IIRC.
[15:21:15] <wiesand> yikes
[15:22:26] <meffie> yikes?
[15:22:27] <kadukoafs@gmail.com/barnowl772461F2> But mayyybe that is not needed for a minimum viable product
[15:22:40] <kadukoafs@gmail.com/barnowl772461F2> Since there's a compatibility mapping
[15:22:50] <kadukoafs@gmail.com/barnowl772461F2> But it's been years since I looked at that spec
[15:23:00] <wiesand> Mike: yikes == "omg"
[15:23:01] <meffie> at least we have a spec now :)
[15:24:02] <mvita> I'll have to read it again.
[15:24:07] <meffie> a new vldb format will be needed for non-crippled IPv6 support as well
[15:24:22] <mvita> yes, that one's inescapable
[15:25:28] <wiesand> Maybe we should make up our mind regarding the relative priorities of rxgk vs. ipv6?
[15:25:29] <meffie> at least for the address records. we can use extents, but there's a fixed space.
[15:26:17] <mvita> right, the extents are the logical place, but it will still be a new format logically
[15:26:22] <meffie> i think there are some parts that have to be done at the same time, and other parts that are parallel
[15:27:13] <kadukoafs@gmail.com/barnowl772461F2> Might be worth trying to write them down in email form
[15:27:16] <meffie> because you dont want to change the vldb format twice (or more;)
[15:27:47] <wiesand> I'd rather not change it a ll if that can be avoided...
[15:27:49] <mvita> mike's typing changes for IPv6 groundwork can go in any time, before or after rxgk
[15:27:50] <kadukoafs@gmail.com/barnowl772461F2> Well ... if only developers are running the code, and it's behind a
dedicated command-line flag with a big scary warning ... maybe it's
not so bad.
[15:28:00] <mvita> because they produce no functional change
[15:28:33] <meffie> correct.
[15:28:35] <mvita> beyond that, I don't know how I would order rxgk vs ipv6
[15:28:48] <mvita> I think maybe rxgk first is my preference.
[15:28:59] <meffie> i assume so too.
[15:29:15] <kadukoafs@gmail.com/barnowl772461F2> A similar (related?) thing is to, in the cache manager, split
afs_Conn() and friends into DB- and file-server specific variants
[15:29:19] <mvita> security has got to be fixed
[15:29:30] <mvita> yes.
[15:29:33] <mvita> please
[15:29:53] <mvita> that's a very good one, I've tangled with that myself on occasion
[15:30:08] <wiesand> IMHO rxgk is overdue while ipv6 is a new feature obviously not strictly required on any existing afs site
[15:30:16] <kadukoafs@gmail.com/barnowl772461F2> (Since we will need to use different tokens to talk to them via rxgk,
as well as for clarity of what's going on in the code)
[15:30:17] <mvita> agreed
[15:30:28] <mvita> (w/ wiesand)
[15:30:33] <meffie> wiesand: agreed
[15:30:55] <kadukoafs@gmail.com/barnowl772461F2> (Also agreeing with wiesand)
[15:31:13] <mvita> BUT DOES WIESAND AGREE WITH WIESAND????
[15:31:26] <meffie> good question.
[15:31:35] <mvita> <trembles w/ anticipation>
[15:31:45] <meffie> i'm going to say yes.
[15:31:49] <wiesand> YES HE DOES
[15:32:02] <mvita> \o/
[15:32:12] <wiesand> (this time around, anyway)
[15:33:16] <meffie> oh, minor question for ben regarding post 1.8.x. can we fix "aklog akimpersonate"?
[15:33:47] <meffie> it works only for 1.6.x at the moment, because, something to do with krb5 libs ?
[15:33:59] <kadukoafs@gmail.com/barnowl772461F2> Sure, we can make it work again
[15:34:05] <mvita> wow
[15:34:31] <meffie> i use that feature a lot, so i have to keep an old 1.6.x aklog around. it's a pain point :)
[15:35:00] <meffie> yay.
[15:35:13] <mvita> no, the workaround is a piece of cake compared to the pain point of following why it doesn't work on master
[15:35:43] <meffie> it's to do with how we try to avoid krb5 libs, if i recall.
[15:36:08] <mvita> a maze of twisty little passages
[15:36:09] <meffie> maybe it needs to be a configure option?
[15:36:25] <kadukoafs@gmail.com/barnowl772461F2> I don't expect a configure option to be particularly helpful there
[15:36:42] <meffie> anyway, ben if you could point me in a direction, i could work in it, since it bothers me.
[15:37:15] <meffie> (e.g. it's only for testing)
[15:37:42] <kadukoafs@gmail.com/barnowl772461F2> I look very skeptically at the
int allowed_enctypes[] = {
            ENCTYPE_DES_CBC_CRC, 0
        };
[15:37:59] <kadukoafs@gmail.com/barnowl772461F2> We may have just removed that entirely from 1.6 and forgot to get
master/1.8
[15:38:21] <wiesand> Unlikely
[15:38:48] <meffie> well, maybe, because it was a security release, so went into stable first, if i recall.
[15:39:00] <wiesand> I hope I'd remember such a 1.6-only change
[15:39:07] <kadukoafs@gmail.com/barnowl772461F2> See 95d57c74476c5a02ce6d9ca913dcbf88ac5c1143
[15:39:21] <wiesand> Ah, those "beloved" security releases...
[15:40:13] <kadukoafs@gmail.com/barnowl772461F2> So, just pass NULL instead of that array, is my guess at what's
needed.
[15:40:18] <wiesand> To repeat my stance on those, "don't do it"
[15:40:38] <kadukoafs@gmail.com/barnowl772461F2> Since your keytab doesn't have a 1DES key anymore (right???), so you
don't find a server key in which to encrypt the printed ticket.
[15:41:28] <meffie> ok, thanks for the hint. i'll take a look.
[15:41:35] <kadukoafs@gmail.com/barnowl772461F2> For master we didn't need to move get_credv5_akimpersonate into
libauth (since the KeyFileExt let the ClientAuth routines use the real
keys directly), so we didn't touch the aklog line as part of the
ancillary cleanup.
[15:42:03] <meffie> ah
[15:42:52] <meffie> noted, thanks.
[15:43:01] <mvita> yes, thank you Ben.
[15:43:46] <wiesand> Looks like we're done for today?
[15:43:48] <kadukoafs@gmail.com/barnowl772461F2> We could probably even sneak that into 1.8.0pre2 if you're quick
[15:43:58] <kadukoafs@gmail.com/barnowl772461F2> I don't have anything else for today, no.
[15:44:30] <kadukoafs@gmail.com/barnowl772461F2> Though I should probably dig up my list of rxgk-related tasks that are
smaller/more-manageable chunks and send it in email form
[15:45:05] <wiesand> Reminder: I'll be on leave August 20th til end of September
[15:45:11] <wiesand> :) :) :)
[15:45:43] <kadukoafs@gmail.com/barnowl772461F2> Anyway, thanks everybody
[15:45:43] <meffie> > We could probably even sneak that into 1.8.0pre2 if you're quick
oh man! that is some incentive! thanks!
[15:46:14] <wiesand> No firm plans yet, but worst case I'll simply be unavailable during that time.
[15:46:44] <meffie> have a good holiday!
[15:46:46] <mvita> have an excellent time, Stephan
[15:47:18] <wiesand> CU next week then. Thanks a lot everyone!
[15:47:47] <mvita> thank you
[15:48:47] wiesand leaves the room
[15:52:13] meffie leaves the room
[17:01:58] meffie joins the room
[21:37:20] meffie leaves the room