- Wednesday, August 5, 2015

release-team@conference.openafs.org

Wednesday, August 5, 2015< ^ >

Room Configuration

Room Occupants

GMT+0
[12:38:29] wiesand joins the room
[13:45:39] meffie joins the room
[13:54:29] <wiesand> Hello Mike. Still on vacation?
[13:54:29] jhutz@jis.mit.edu/owl leaves the room
[13:58:39] kaduk joins the room
[13:58:39] <shadow@gmail.com/barnowlC9C9D81E> hi
[13:58:57] <wiesand> Hi. You’re not the room today :)
[14:00:18] mvita joins the room
[14:00:49] <wiesand> Hello Mark
[14:00:55] <mvita> greetings
[14:01:05] <Jeffrey Altman> hi
[14:01:16] <Jeffrey Altman> conflicting meetings today
[14:01:23] <Jeffrey Altman> workshop planning.
[14:01:31] <wiesand> Hi. Glad you’re here anyway.
[14:01:45] <Jeffrey Altman> the regex changes require reviews and then they can be merged
[14:02:04] <wiesand> Right.
[14:02:17] <mvita> I was looking at them just before the mtg
[14:02:24] <mvita> for 1.6, that is
[14:03:40] <wiesand> And?
[14:04:10] <mvita> not done yet
[14:04:47] <wiesand> Take your time. Let’s strive for a release without another regression.
[14:05:12] <mvita> I'm looking at other possible regex users
[14:05:13] <wiesand> I still hope we can het 1.6.14 out this week.
[14:05:28] <wiesand> I was thinking about “vos backupsys” ?
[14:05:34] <mvita> in particular, if there are libadmin consumers that are not in tree
[14:05:40] <mvita> vos backupsys does not
[14:05:48] <mvita> no vos command doe
[14:05:50] <mvita> does
[14:06:25] <mvita> and the libadmin routine (VLDB_ListAttributesN2) that _could_ use regex has no callers in the AFS tree
[14:06:38] <mvita> so my question is about out-of-tree users of libadmin
[14:06:39] <wiesand> So the regular expressions you can specify to vos backupsys are processed by vos, not the vl server?
[14:07:15] <mvita> dunno, looking
[14:07:21] <wiesand> And btw, this is an embarrassing question, but what is libadmin anyway?
[14:08:03] <mvita> yup, looks like those regex are resolved in vos itself (userspace)
[14:08:14] <mvita> not on the VL server side
[14:08:24] <wiesand> Fine, thanks.
[14:09:00] <mvita> then it calls VL_ListAttributes, not ListAttributesN2
[14:09:06] <wiesand> I’m just asking because it would be nice to have a statement in the announcement and the release notes what was actually broken.
[14:09:14] <mvita> yes.
[14:09:20] <mvita> that's what I would like as well
[14:09:25] <mvita> and that's why I'm making this list
[14:10:53] <mvita> the only other in-tree potential user of VL_LAN2 regex is vlclient, a debug utility
[14:11:25] <wiesand> Gatekeepers, is it ok to do the revert on the 1.6 branch rather than pulling up 11967?
[14:11:32] <mvita> we also want to say in the release notes that backup (known in-tree user) only requires it in certain circumstances
[14:12:20] <mvita> and that, as Jeffrey correctly noted, the superuser requirement is not onerous for backup because it is already documented to require superuser on the vlserver and backupserver
[14:12:33] <wiesand> Only when regexs are used to specify servers/partitions/volumes?
[14:13:13] <mvita> so our only concerns for further "brokeness" are out of tree users of libadmin, out of tree users of the VL RPC, and vlclient
[14:13:39] <mvita> I don't think we care about vlclient - anyone using that for debugging will certainly be using localauth
[14:14:03] <mvita> only when regex is used for volume names
[14:14:07] <Jeffrey Altman> wiesand: you can revert on 1.6
[14:14:31] <mvita> the server and partition "wildcards" are special cases that don't use regex
[14:14:51] <wiesand> Ah. Never used backup...
[14:15:00] <mvita> and the special case of no volume name or all volume names also do not use regex
[14:15:31] <mvita> only if you actually specify a volume name (or partial name) is regex logic invoked on the vlserver side
[14:16:05] <wiesand> I think this announcement / NEWS entry should be drafted by someone with more insight into the details than me ;-) Volunteers?
[14:16:36] <mvita> so essentially this problem only affects backup users with volumesets that specify backups by volume name or volume naming convention
[14:16:57] <mvita> I am willing to draft it and then have others approve
[14:17:39] <wiesand> Thanks. release-team@ is probably the place to discuss it.
[14:18:34] <wiesand> Do we want 11970 as part of 1.6.14?
[14:18:42] <mvita> oh, sorry, missed your earlier question about libadmin
[14:18:52] <mvita> I'm not sure I know what it is mysefl.
[14:19:11] <wiesand> :-)
[14:19:13] <mvita> but I think of it as programmatic vos
[14:19:33] <Jeffrey Altman> libadmin is a portable library that provides some of the functionality of bos, vos, pts, fs, and configuration
[14:19:34] <mvita> it does that same things as vos, but from your own bindings or programs
[14:19:54] <wiesand> Ah. Thanks.
[14:20:19] <mvita> it is bitrotted - things that get fixed or added to vos don't usually also get fixed or added to libadmin equiv.
[14:20:29] <Jeffrey Altman> it is used in tree for the user manager and server manager GUIs on Windows and there are third party management consoles that build against it
[14:20:48] <mvita> a few years ago we looked at updating libadmin and then converting vos to use it
[14:20:53] <Jeffrey Altman> it was never a complete implementation of the command line tool functionality
[14:20:55] <mvita> but .... no money and no time
[14:21:19] <mvita> and no real demand
[14:21:42] <mvita> other than the desire to eliminate a source of duplicated function
[14:22:34] <wiesand> Is it built/installed by default on Unix?
[14:22:43] <mvita> umm
[14:22:49] <mvita> I think so, I don't know so
[14:23:42] <mvita> jeffrey, do you have a list of 3rd party users?  is it things like afs::command (the perl bindings)?
[14:23:53] <Jeffrey Altman> no
[14:24:03] <Jeffrey Altman> it is built everywhere
[14:24:21] <wiesand> Yes, found it in my packages.
[14:25:00] <mvita> so I think the best we can do is call that out and let the libadmin users sort for themselves whether they are affected
[14:25:47] <mvita> unless they are in our tree of course - I wasn't aware of the windows gui tools that used it
[14:26:03] <mvita> are they affected by this?
[14:27:23] <mvita> jeffrey said :  "no"  but it wasn't clear to me which question you were answering
[14:28:09] <wiesand> list pf 3rd party users, I guess
[14:30:13] <wiesand> I think 1.6.14 is well on track then, except that I’m still unsure whether to include 11970
[14:32:57] <mvita> looking now, Stephan
[14:33:46] <Jeffrey Altman> the "no" referred to the list of out of tree users.   There is no such list.
[14:33:47] <mvita> I say no
[14:33:54] <mvita> for 11970
[14:34:16] <mvita> the only in-tree user is the previously mentioned vlclient
[14:34:23] <mvita> a little-used utility
[14:34:56] <meffie> (that is intended for developers only)
[14:35:01] <mvita> that too
[14:35:04] <Jeffrey Altman> 11970 is a fix to code that isn't compiled.  it doesn't matter
[14:35:11] <mvita> very easy to ruin your day w/ vlclient
[14:35:12] <wiesand> Fine, thanks. That one’s for 1.6.15 then.
[14:35:27] <mvita> yup
[14:35:43] <meffie> (anyone can make a program to call rpcs, you dont have to use vlclient:)
[14:37:47] <wiesand> Ben found nit in 11969’s commit message...
[14:37:54] <Jeffrey Altman> the reason that regex is being restricted to superusers is because processing a request can require a great deal of memory and resources and since vlserver is single threaded it can also have adverse impact on all other RPC that must be processed including ubik elections.   It is completely feasible to denial of service a vlserver and cause loss of quorum.
[14:39:16] <mvita> ah, wasn't aware of that aspect of the problem - but then I wasn't aware of any aspect of the problem until the fix was released, and it gave few details of the risks.
[14:39:41] <mvita> I was hoping the cve would give more info, but they hadn't been updated yet
[14:39:53] <Jeffrey Altman> the problem I describe is not limited to regex calls.
[14:39:56] <mvita> but the last time I looked was last week
[14:40:31] <Jeffrey Altman> regex calls are just a really bad case
[14:40:38] <mvita> nod
[14:42:33] <Jeffrey Altman> Ben's comment on 11969 is a choice of language.  it is not something in my opinion needs to be fixed.
[14:42:43] <mvita> just checked cve-2015-3285 - still no details published there
[14:43:41] <wiesand> Jeff: good. How much more review do they need? NB is there feedback from the testers?
[14:45:00] <Jeffrey Altman> I've merged them
[14:45:56] <wiesand> Thanks. I’ll repush the 1.6 revert and pull them up on top of it.
[14:46:25] <shadow@gmail.com/barnowlC9C9D81E> i've heard no acks to my emails to them. i hear they run up to two
weeks behind
[14:47:06] <shadow@gmail.com/barnowlC9C9D81E> (cves)
[14:47:25] <mvita> yeah, I think they (mitre) do get very backed up
[14:47:41] <mvita> so I'm not complaining, just noting.
[14:49:12] <wiesand> So, 1.6.14 is on track. On to 1.6.14.1... any bearers of Linux news around?
[14:49:43] <mvita> at any rate, the vlserver regex thing was the one with no CVE, so it's moot for our discussion on that
[14:50:01] <wiesand> Right.
[14:50:21] <Jeffrey Altman> linux 4.2 is very unstable at the moment.
[14:50:47] <wiesand> Linux 4.2 or our client on it?
[14:51:37] <wiesand> The other 1.6.14.1 related question mark is behind 11945.
[14:52:16] <Jeffrey Altman> Linux 4.2
[14:52:48] <wiesand> So it may take a bit longer, I guess.
[14:53:59] <wiesand> Conveying a message from Ben: “The MITRE folks generally are glacial about updating the CVE description
unless someone points out information to them post-embargo. They also
tend to just re-use upstream's text without doing much interpretation.
Sorry I can't talk in the room; my jabber client is failing to connect to
MIT's server.”
[14:56:02] <wiesand> 11945: I failed to provoke any breakage on EL5/6/7 clients. But then I don’t run with fakestat-all for example.
[14:56:24] <wiesand> But I guess it’s all the testing we’ll get...
[14:56:45] <Jeffrey Altman> I'm trying to see if Marc can join to ask about specific testing
[14:57:51] marc joins the room
[14:57:58] <marc> howdy
[14:58:11] <wiesand> Like magic :)
[14:58:14] <wiesand> Hi Marc
[14:58:57] <wiesand> We’re talking about 11945 (eloop)
[14:59:09] <marc> ideally we'd have someone who was able to trigger the original problem (oopses in may_delete, etc.), but maybe that's hard to find at this point
[14:59:53] <wiesand> Crashing EL5 with 1.4.15 was really easy ;-)
[15:01:56] <wiesand> Given our resources, the only way to find out is to put it into a release.
[15:02:38] <marc> andrew's opinion might be interesting, but not sure how much he's available these days
[15:03:50] <wiesand> I’ll pester him. Worst case he’ll tell me to get lost ;-)
[15:04:55] <mvita> I can pester him too.
[15:05:08] <mvita> I'm used to him telling me to get lost.
[15:05:21] <marc> reading back, i've seen many odd things in the current 4.2 kernel.  but nothing clear or specific enough to report upstream yet
[15:05:24] <wiesand> Good. Please, go ahead.
[15:05:28] <mvita> it hardly hurts at all any more.
[15:05:41] <mvita> ;-)
[15:06:26] <wiesand> Are others seeing 4.2 instabilities too?
[15:07:12] <marc> i've seen a few reports.  my use case may be particular, i mainly see issues while making heavy use of docker (for testing)
[15:08:01] <wiesand> lxc + pags/tokens?
[15:08:54] <marc> this is just user space, so no kernel module involved
[15:09:26] <wiesand> Ah. Anyway, do you expect a longer than usual release cycle?
[15:10:35] <marc> doesn't sound like it at the moment
[15:11:05] <wiesand> Pity. But the changes on our pipeline would still suffice?
[15:12:00] <marc> yes, everything builds and runs ok.   i've only seen the issues while running docker (but i do that a lot)
[15:13:51] <wiesand> Thanks. Is seems the worst case would be we chicken out of 11945 and paths are limited to 40 components on newer kernels.
[15:14:25] <wiesand> Not pretty, but not the end of the world.
[15:14:25] kaduk leaves the room
[15:15:12] <marc> yeah im not sure how much of an issue that will be.  maybe for a few use cases.
[15:15:55] <wiesand> It will be hit in some cases, like every limit.
[15:16:00] <marc> note that the failure is temporary.  if you retry it will succeed (as long as it's < 80 components)
[15:16:46] <Jeffrey Altman> it will kill at least one site.
[15:16:57] <wiesand> Not much comfort. I’m not even sure which behaviour I’d choose if I could.
[15:17:34] <wiesand> Can that site test 11945 thoroughly?
[15:17:48] <wiesand> Frankly, I’m not sure I care as far as my clients go.
[15:18:22] <Jeffrey Altman> the two sites that I think are going to be impacted by a 40 component path limit on Linux are sna customers
[15:19:24] <wiesand> Should I hand out the weapons now?
[15:19:38] <Jeffrey Altman> the weapons?
[15:19:44] <marc> but it may be a while before they run a 4.2 kernel, depending on the distro
[15:19:52] <wiesand> Jeff: forget it.
[15:20:38] <Jeffrey Altman> I don't have access to the technical contacts that could perform the testings.
[15:20:58] kaduk joins the room
[15:20:58] kaduk leaves the room
[15:20:59] <mvita> I will talk to deason about this and see what we can do.
[15:21:49] <wiesand> Good.
[15:22:03] kaduk joins the room
[15:22:18] <kaduk> I see I'm just in time for things to be wrapping up...
[15:22:24] <Jeffrey Altman> I am leaning to including the eloop change along with the 4.2 support.  I would dislike changing the behavior later unless we hear that it breaks something else.
[15:23:30] <shadow@gmail.com/barnowlC9C9D81E> i think i'd include the eloop change
[15:24:07] <wiesand> Sounds like the thing to do then, unless Mark comes back with a showstopper.
[15:24:43] <wiesand> Hi Ben. Glad you made it.
[15:25:33] <mvita> I have no opinion on eloop.  I know deason does because we discussed it - but I can't remember what he said  :-/
[15:25:35] <kaduk> Thanks.
Putting in the eloop change seems reasonable in principle, though I haven't looked at it closely
[15:27:11] meffie leaves the room
[15:28:01] <wiesand> Ok. We have another week before we must decide this. Let’s see if we get new input, in particular showstoppers. If there are none. let’s put it in then.
[15:28:14] <mvita> > unless Mark comes back with a showstopper.     itym Marc?
[15:28:24] <Jeffrey Altman> Next week is the workshop.   I doubt any of us will be able to attend a meeting
[15:28:57] <mvita> workshop is in 2 wks
[15:28:58] <Jeffrey Altman> sorry, not next week.   the week after
[15:28:58] <kaduk> I thought that was in two weeks
[15:29:05] <wiesand> Mark: no, I meant Mark. (“I’ll talk to deason and see what we can do”)
[15:29:12] <mvita> ah, okay
[15:30:18] <wiesand> So next week’s will be the last meeting for a while.
[15:31:22] <shadow@gmail.com/barnowlC9C9D81E> ok
[15:32:09] <wiesand> We should manage to get 1.6.14, 1.6.14.1 ready then.
[15:33:06] <wiesand> My vacation starts during the workshop, and extends to the end of September.
[15:33:30] <wiesand> I don’t say I won’t look at openafs at all during that time. But I won’t make commitments.
[15:33:32] <Jeffrey Altman> enjoy
[15:34:02] <wiesand> And who knows what the situation will be after the workshop ;-)
[15:35:13] <wiesand> It’s late. Let’s skip the “1.6.13 debriefing”. I’m not sure anything would come out of it anyway.
[15:35:39] <Jeffrey Altman> have a good night.  and thank you
[15:35:53] <mvita> tx everyone - later...
[15:35:55] <wiesand> And Daria: thanks a lot for making it possible at all.
[15:36:06] <marc> later everyone
[15:36:07] <mvita> yes, agreed, thank you Daria
[15:36:10] marc leaves the room
[15:36:16] <wiesand> Thanks a lot everyone!
[15:36:38] wiesand leaves the room
[15:38:58] kaduk leaves the room
[19:07:29] mvita leaves the room
[21:36:25] mvita joins the room