- Wednesday, December 10, 2014

release-team@conference.openafs.org

Wednesday, December 10, 2014< ^ >

Room Configuration

Room Occupants

GMT+0
[03:22:56] Jeffrey Altman leaves the room
[03:36:11] Jeffrey Altman joins the room
[09:12:01] shadow@gmail.com/barnowlE5B64A04 leaves the room
[09:12:11] shadow@gmail.com/barnowlE5B64A04 joins the room
[09:19:39] shadow@gmail.com/barnowlE5B64A04 leaves the room
[09:19:49] shadow@gmail.com/barnowlE5B64A04 joins the room
[09:29:28] shadow@gmail.com/barnowlE5B64A04 leaves the room
[09:29:36] shadow@gmail.com/barnowlE5B64A04 joins the room
[14:43:02] meffie joins the room
[14:56:49] kaduk joins the room
[14:57:39] wiesand joins the room
[15:00:10] <kaduk> $timeofday
[15:00:18] <wiesand> Hi!
[15:01:39] <meffie> hello
[15:01:55] <kaduk> How is Jeffrey's internet connection doing?
[15:02:45] <wiesand> Hm
[15:03:44] <wiesand> Fine. Let’s see what we can get done given the attendance...
[15:04:08] <wiesand> Does anyone have anything to say regarding 1.6.11/Linux?
[15:04:30] <kaduk> Andrew did the work to get pre1 in debian experimental
[15:04:43] <meffie> yay
[15:04:56] <kaduk> But that only happened, like, yesterday, so we haven't heard anything about it.
[15:05:02] <wiesand> Good. What kernel is that?
[15:05:15] deason joins the room
[15:05:39] <kaduk> Looks like there's not a kernel in experimental, so the same as unstable -- 3.16
[15:06:15] <wiesand> We should be ok then.
[15:06:25] <kaduk> *nods*
[15:06:54] <wiesand> But the 3.17.3+ thing is pretty ugly, if true.
[15:07:08] <kaduk> Yeah, that one looks un-fun.
[15:07:42] <wiesand> Marc said he’d submit a change, but it seems to take time.
[15:08:25] <kaduk> We could send him email asking how it's going, I guess.
[15:08:28] <wiesand> I think there’s no point in releasing 1.6.11 before that’s fixed.
[15:08:37] <wiesand> I’m going to pm Marc.
[15:09:02] <kaduk> Okay.
[15:09:06] <kaduk> Should we move on, then?
[15:09:11] <wiesand> Andrew, anything from your volunteer testers?
[15:09:32] <wiesand> If not, let’s move on to “1.8”.
[15:11:08] <kaduk> Well, the 11615/11616/11326 issues affect both 1.6 and 1.8.
[15:11:43] <wiesand> Right. I just assume that in the end we’ll pull up from master.
[15:12:07] <kaduk> It seems that 11616 might be enough for 1.6, as Andrew posited when he submitted it.
[15:13:15] <kaduk> Though, hmm, the scripts.mit.edu folks are still doing a lot of reboots, so I should probably try to check in with them about what they're running and what the BUGs are.
[15:13:19] <deason> nothing from testers yet, it's too soon
[15:13:38] <deason> 11616 isn't helpful; I thought they were hitting that new linux incompatibility
[15:13:39] <wiesand> Thanks.
[15:14:22] <kaduk> That would make more sense, yes.
[15:15:11] <kaduk> But does that make these three changes non-issues?  Should they be abandoned, or should we look at them?
[15:16:44] <wiesand> I invited review from the CERN folks, where fix_bad_parent came from, nut no reaction yet.
[15:16:48] <deason> the fix/check_bad_parent path should still be removed if it doesn't actually do anything
[15:17:21] <deason> I'm not sure why CERN would know, it's been there since openafs 1.0
[15:17:26] <wiesand> Is there any evidence that it’s doing harm?
[15:17:50] <wiesand> Sure?
[15:18:12] <deason> it's just slower, in a hotpath
[15:18:38] <deason> 11616 could probably be abandoned, though; I just want to check on the details
[15:19:42] <kaduk> Okay.
[15:19:52] <kaduk> Do you want to say anything about 11615 vs. 11326?
[15:24:14] <kaduk> I guess not?
[15:25:15] <deason> 11326 still causes extra lookups; as far as I know it can just be removed
[15:25:49] <kaduk> Ah.
Should we comment to that effect on 11615 and 11326 (or did we already and I'm being dumb)?
[15:27:34] <deason> ...just that I prefer 11615?
[15:28:06] <kaduk> that you think the bits in 11326 not in 11615 cause extra lookups which are not needed
[15:29:23] <deason> well of course it does; 11326 doesn't remove the parent-checking functionality, it just refactors it
[15:29:49] <kaduk> The "Andrew thinks are not needed" is not obvious from the change.
[15:30:42] <deason> I'm not sure, which is represented in 11615
[15:30:54] <deason> these changes are also not terribly important; it doesn't seem useful to be discussing them here
[15:31:00] <kaduk> Okay.
[15:31:05] <kaduk> Let's move on, then.
[15:31:10] <kaduk> Looking at the list of gerrit changes I sent out, the Jeffs commented about the additional volume header time update bits, and I think I agree with what was said.  Someone (TM) should do the patch to handle V_backupDate(vp) being not set.
[15:31:14] <wiesand> If it’s just an optimization....
[15:32:25] <kaduk> The discussion about whether changes to non-vnode data should change the update time can probably be deferred until after 1.8
[15:33:29] <wiesand> Given the available development resources, if you block 1.8 on “it could be done even better”, IMHO you can just as well forget about it.
[15:33:41] <kaduk> Yeah...
[15:34:21] <kaduk> I guess we can let discussion about vos changeaddrs vs. mh entries continue on the list; maybe we should even move it to -devel
[15:34:54] <meffie> yeah, sorry, i've not pushed new patchsets yet, need to finish testing.
[15:34:57] <deason> it's more of "who cares about it" than "it could be done better" to me
[15:37:22] <kaduk> Regarding the byte-range locks lock order issue, jhutz was maybe going to look more.
jaltman thinks that Simon's scheme should not be too hard to implement, so maybe I can take a stab at it.  I'm not sure that I could do any meaningful testing of such a patch, though.
[15:38:43] <wiesand> I figure Hans-Werner would help out, running his test case. Would that suffuce?
[15:39:03] <kaduk> Probably.
[15:39:54] <kaduk> There's probably not much for us to do here about the list of issues that I had asked for jaltman input on.
[15:40:09] <kaduk> Mike, do you have plans to make a README.md submission?
[15:40:33] <meffie> hmm, i suppose i can do that.
[15:40:43] <deason> iirc, the approach mentioned by simon has more chances to introduce bugs, for rather small gains...
[15:41:27] <kaduk> Well, I guess we won't know until we have something to look at.
[15:41:39] <kaduk> If there are two options to compare, that may help us move forward.
[15:42:35] <kaduk> (next item)
I should go submit a cherry-pick of 10019 that doesn't depend on a broken change, to see if it builds.  Not really much to talk about on that, I guess :)
[15:43:53] <kaduk> Andrew, do you want to say anything about 8841 (prevent out-of-bounds FD_SET calls)?
[15:44:25] <kaduk> Something Jeff said about certain Unices allowing values larger than the compile-time constant tickles a memory somewhere
[15:45:00] <Jeffrey Altman> internet install now complete.
[15:45:40] <wiesand> Welcome
[15:45:43] <kaduk> Welcome back :)
[15:45:56] <kaduk> Was this a speed boost?
[15:47:00] <deason> something like 8841 would be good to have, but it's not a priority
[15:47:24] <kaduk> Okay.
[15:47:38] <kaduk> I was about to say, "we probably don't need to care about getting something in for 1.8" ;)
[15:48:29] <kaduk> Next item: fileserver tuning
[15:48:40] <Jeffrey Altman> this is IPv6
[15:49:12] <kaduk> If we did give people the option of just specifying a memory footprint, what values would be tuned according to it?
[15:51:36] <deason> callbacks and threads are the biggest ones; for everything else, I think you could just use s/m/l values based on the specified memory if you don't want to come up with anything more specific
[15:51:41] <kaduk> From looking at my strawman in 11528, number of callbacks, probably vhashsize, maybe udpBufSize
[15:52:02] <kaduk> "threads" meaning the "lwps" variable?
[15:52:37] <deason> ah yeah, udp receive size would be good, too
[15:52:49] <deason> I'm not looking at the code, but that sounds right
[15:52:49] <kaduk> I was not thinking about making this memory-footprint option do anything clever for values smaller than, say, 100M.
[15:53:11] <kaduk> If you want a footprint smaller than that, small/medium/large may actually be okay for you
[15:53:45] <meffie> yes
[15:53:46] <deason> that's what I mean; just setting it to s m or l based on the value given is a fine first version nof it
[15:54:21] <kaduk> I'm not sure I understand your meaning.
[15:55:49] <kaduk> Are you saying we should make a -memory-footprint N flag which just splits things into s, m, or l based on the given N, with no handling for very large N?
[15:58:41] <kaduk> (peeking ahead at the next item)
Jeff had commented on 11305 (changing AFSCONF_UNKNOWN's error string); since this is an OpenAFS-internal error table, I don't see anything wrong with just making a new error constant and using it (leaving the existing string unchanged).
[15:59:55] <deason> I mean you have a -mem flag, and even if you don't make it do anything 'fancy' for higher memory, you can just let it assign s m or l for now, and it's better than we have
[16:00:02] <wiesand> I still think a new fileserver switch shouldn’t block anything...
[16:00:47] <deason> it should set more values, but it doesn't need to to be an improvement, imo
[16:00:52] <kaduk> Okay, thanks for clarifying
[16:01:45] <kaduk> In practice, it probably wouldn't actually block anything.  It's just "my personal pet project" for a bit :)
[16:02:00] <wiesand> Ah. Fine.
[16:02:22] <kaduk> If there are no objections to the "add a new AFSCONF_ error code" proposal, let's move on to the next item.
[16:02:59] <kaduk> 11124: linux mmap recursion
[16:04:54] <wiesand> Does it address a regression w.r.t. 1.6?
[16:06:45] <kaduk> "It doesn't say."
[16:07:24] <Jeffrey Altman> 11124 is a bug in 1.6
[16:07:31] <kaduk> linux-mmap-antirecursion-20081020
[16:08:51] <kaduk> I don't know that we need to talk about the technical aspects of the proposed solution(s) here today, I just wanted to ask if we want to try to fix it for 1.8 (or 1.6, for that matter).
[16:09:24] <kaduk> If it is considered to be a minor enough bug(fix), it could go in after a release in the normal mechanism
[16:09:52] <Jeffrey Altman> the bug is real.   the fix is not.
[16:10:22] <kaduk> Sounds like we should mark 11124 as -2 for now, then.
[16:10:54] <Jeffrey Altman> its a fix for 1.6 when it is ready.   it doesn't need a -2
[16:11:11] <Jeffrey Altman> its not a blocking change
[16:11:21] <kaduk> (next item)
Any objections to 11601 (remove CellServDB and ThisCell symlinks from redhat init script)?
[16:11:51] <Jeffrey Altman> I am not familiar enough with the packaging to have a valid opinion
[16:13:14] <meffie> it was quite a surprise when my server's csdb was clobbered.
[16:14:05] <kaduk> Hearing nothing much, let's move on.
[16:14:22] <Jeffrey Altman> I don't think that packaging should be doing anything to the server cellservdb.
[16:14:34] <Jeffrey Altman> who wrote that bit of code?
[16:14:39] <meffie> neither do i
[16:14:39] <wiesand> I don’t understand that semicolon the change adds, but otherwise it looks fine.
[16:15:14] <kaduk> The semicolon should not be needed, but neither is it harmful
[16:15:38] <wiesand> That’s why I =1’ed it anyway :-)
[16:16:06] <kaduk> The last item on the list I sent out yesterday is OSD.
[16:16:43] <kaduk> The claiming of an element of the rx_securityClass is not a wire change as jhutz had asked, but just locking us into an ABI.
[16:18:53] <Jeffrey Altman> Its not only locking us into an ABI but its committing us to permitting reuse of a key for OSD services that are outside of Rx
[16:19:04] <kaduk> That, too, yes.
[16:19:30] <kaduk> It seems that the diagnosis of no one other than Hartmut willing to put time into moving it forward is accurate, though.
[16:20:40] <wiesand> I’ll assert that there is no way to get it past the gatekeepers whatsoever.
[16:20:56] <Jeffrey Altman> My perspective is that it is fine for OpenAFS to host a plug-in interface for OSD libraries such that OSD development and OpenAFS development can continue along independent time frames.   I have long objected to the idea that OSD should be a standard part of OpenAFS.
[16:21:19] <kaduk> I cannot argue against that opinion.
[16:21:45] <Jeffrey Altman> wiesand: that is not true.
[16:22:25] <Jeffrey Altman> When we met with Hartmut in Edinburgh and did a protocol review of OSD we found significant opportunities for the OSD protocol to corrupt user data.
[16:22:43] <wiesand> It wasn’t possible with the cash we had in our pockets in Rome...
[16:23:17] <wiesand> And that sum is unlikely to be available ever again for this purpose.
[16:23:28] <Jeffrey Altman> what cash?
[16:23:46] <Jeffrey Altman> There is no question of money here.
[16:24:07] <Jeffrey Altman> OSD was not suitable for deployment on a public Internet
[16:24:15] <Jeffrey Altman> Nor was it supportable.
[16:24:24] <kaduk> [obligatory note that logs of this room are public]
[16:25:20] <Jeffrey Altman> I forget where the last face to face design meeting was.  It might have been at DESY.
[16:25:44] <kaduk> Jeffrey, do I read your mail correctly that there is not really any current action item for 1.8 regarding RX_PACKET_TYPE_BUSY race or the rx_multi short circuit?
[16:26:32] <Jeffrey Altman> I am going to assume it was DESY for the purpose of this discussion.   Prior to DESY, the OSD functionality was being grafted into existing AFS3 service RPCs.  As a result all of the changes had afs3 standardization issues.
[16:27:42] <Jeffrey Altman> At DESY I came up with the idea of creating a separate set of OSD Rx Services that would run on the same port numbers as the AFS3 Rx services.   That would avoid the standardization issues and permit the new services to be implemented as a set of plugin libraries.
[16:29:13] <wiesand> I recall the plugin model being the only realistic solution.
[16:29:37] <wiesand> Does 10930 adhere to it?
[16:30:29] <Jeffrey Altman> 10930 is an attempt to implement that model.   There are a couple of problems:
1. it is pushing too much into OpenAFS.  Instead of just committing the interface that OpenAFS needs to support it is giving OpenAFS all of OSD.    Only the OpenAFS interface should be submitted to OpenAFS and the rest should remain in a separate OSD repo on github.com or elsewhere.
2. the code and the revised protocol has not been reviewed.   That is hard to do given how large the submission is.
3. Ben has identified at least one issue that would be blocking because OpenAFS should not be exporting an interface change to rx security classes that will get in the way of rxgk.
[16:31:07] <Jeffrey Altman> In Patchset #18 Daria attempted to extract just the bits that would go into OpenAFS.
[16:31:21] <Jeffrey Altman> As a model for Hartmut to follow.  It got stomped on.
[16:33:09] <wiesand> Well, after invitation... (PS19)
[16:33:33] <wiesand> But I completely understand your objections to the change as it is.
[16:34:07] <wiesand> It must not block 1.8 IMHO.
[16:34:31] <Jeffrey Altman> The intention was that Hartmut would model future revisions on the break down that Daria performed.
[16:35:00] <Jeffrey Altman> I do not believe that OSD is anywhere close to being ready because there is no one that is going to take ownership of it.
[16:35:22] <Jeffrey Altman> It should not block 1.8
[16:36:44] <kaduk> Agreed.
[16:37:08] <kaduk> Did you see my 11:25 question?
[16:37:42] <Jeffrey Altman> Your interpretation of my response is correct.
[16:37:48] <kaduk> Okay, thanks.
[16:38:12] <kaduk> It's late enough that we probably should just stop, and not try to dig up last week's list.
We have a decent number of action items.
[16:39:10] <Jeffrey Altman> thanks everyone.
[16:39:48] <wiesand> I’ll call it a day then - unless anyone wants to bring up anything else?
[16:41:06] <wiesand> Taking the silence as a no. Thanks a lot everyone.
[16:41:11] wiesand leaves the room
[16:41:15] deason leaves the room
[16:41:54] meffie leaves the room
[16:43:36] kaduk leaves the room
[17:36:56] kaduk joins the room
[17:45:22] Jeffrey Altman leaves the room
[17:45:22] Jeffrey Altman joins the room
[20:01:13] Jeffrey Altman leaves the room
[20:01:13] Jeffrey Altman joins the room
[20:02:44] Jeffrey Altman leaves the room
[20:02:44] Jeffrey Altman joins the room
[20:27:33] Jeffrey Altman leaves the room
[20:27:33] Jeffrey Altman joins the room
[20:29:25] Jeffrey Altman leaves the room
[20:29:25] Jeffrey Altman joins the room
[20:35:28] Jeffrey Altman leaves the room
[20:35:28] Jeffrey Altman joins the room
[22:46:11] Jeffrey Altman leaves the room
[22:46:11] Jeffrey Altman joins the room
[22:46:27] Jeffrey Altman leaves the room
[22:46:47] Jeffrey Altman joins the room
[23:22:06] kaduk leaves the room