- Wednesday, October 1, 2014

release-team@conference.openafs.org

Wednesday, October 1, 2014< ^ >

Room Configuration

Room Occupants

GMT+0
[03:43:29] Jeffrey Altman leaves the room
[03:52:01] Jeffrey Altman joins the room
[13:27:56] wiesand joins the room
[13:31:45] meffie joins the room
[13:36:24] wiesand leaves the room
[13:38:24] wiesand joins the room
[13:38:49] <wiesand> test
[14:01:32] <meffie> good day wiesand
[14:02:03] <wiesand> Hello
[14:02:26] <wiesand> What a crowd...
[14:03:28] <wiesand> Sigh. I didn't even know about "aklog -path"...
[14:05:40] kaduk joins the room
[14:06:07] <kaduk> Yeah, aklog has a surprisingly large amount of functionality.
[14:07:10] <wiesand> So, no 1.6.10 release before this is fixed. New tarballs, new binaries, ...
[14:07:46] deason joins the room
[14:08:01] <meffie> yeah. i wish the impersonate stuff in aklog was a different program.
[14:08:28] <deason> (I'm distracted, may not be paying much attention)
[14:08:38] <kaduk> Well, it's off in a library on 1.6...
[14:10:07] <wiesand> Not much going on around Linux 3.17 lately either.
[14:10:08] <meffie> yeah
[14:10:29] <meffie> (yeah to ben, i see that)
[14:12:45] <wiesand> So 1.6.10[.1] seem fairly straightforward, even though they'll take more time.
[14:13:06] <wiesand> Which leaves us with 1.6.8 as the topic to discuss, I believe?
[14:13:20] <kaduk> 1.6.8 is done already ;)
[14:13:41] <kaduk> (old finger habits die hard, I know.)
[14:13:42] <wiesand> Hoa about 1.8 then?
[14:13:47] <wiesand> (sorry)
[14:14:43] <kaduk> Well, how do we want to do it.  Last week you had mentioned going through commits one by one.
We also have the items I sent to -devel which got some discussion.
[14:14:51] Marc Dionne joins the room
[14:15:44] <wiesand> I must admit I only read that thread very briefly yet.
[14:16:08] <wiesand> I've been offline most of the time lately. This changes as of today...
[14:17:32] <wiesand> Ben: regarding changes, do you have a list of those you believe are ready and close to getting merged?
[14:18:11] <kaduk> Not exactly.  I was working on some other projects last week, and am just now getting to re-review my stack of patches.
[14:18:17] <wiesand> [Hi Marc. Linux 3.17 got an rc7 - more surprises?]
[14:19:07] <Marc Dionne> hi stephan.  we whould be ok with the 2 changes currently in gerrit, afaict
[14:19:18] <wiesand> Marc: Thanks.
[14:19:34] <Marc Dionne> and release almost surely this upcoming weekend
[14:20:58] <kaduk> I would be somewhat more comfortable if Simon chimed in on one or two of the libtool changes, but I think I do understand what is supposed to be going on.
[14:21:24] <wiesand> Marc: Yes, likely. And we'll barely get 1.6.10 out before...
[14:22:44] <Jeffrey Altman> Ben has reviewed 11455 but no one has reviewed 11492
[14:23:21] <Jeffrey Altman> Simon is swamped
[14:24:33] <kaduk> I'm not sure I consider myself qualified to review 11492.
I could probably ask Anders if he can do so, or maybe Andrew could.
[14:25:16] <kaduk> I don't think that branching 1.8 needs to block on Simon reviewing my libtool changes.
(It will de facto block on him doing other things, of course.)
[14:26:41] <Jeffrey Altman> creating the branch for example
[14:26:51] <kaduk> Exactly :)
[14:28:19] <wiesand> The best way to make progress will be to have a relatively short list of relatively simple things to do next.
[14:29:42] <Jeffrey Altman> Andrew has been working on the dsplice changes with Red Hat.  He is probably in the best position to review Marc's work in that area.
[14:30:20] <kaduk> I guess we can go through the issues I enumerated on -devel, briefly.
[14:30:35] <kaduk> (1) .la files seems clear-cut at this point -- don't install them
[14:31:08] <wiesand> In any case, adding them later will be easier than removing them
[14:31:26] <Jeffrey Altman> agreed
[14:31:32] <kaduk> (2) SONAME bumps
Also seems pretty clear, since Chas has pointed out places where we did change the ABI incompatibly.
Well, only for afsrpc and afsauthent, I suppose.  libkopenafs may not have changed, but I don't think that a SONAME bump is a big deal there.
[14:32:10] <Jeffrey Altman> if we changed the abi, bump the soname
[14:32:27] <kaduk> (3) web plugin
We're de facto not really maintaining it, so it's probably best to jettison it.
[14:32:43] <kaduk> (For (2), the current changes in gerrit do bump the SONAME already, so they do not need to change.)
[14:33:41] <kaduk> (4) fileserver tuning
Chas thinks that concrete proposals may be contentious.  But, we don't have any concrete proposals to talk about.  This would probably be a "relatively simple thing to do" if someone is interested...
[14:34:27] <wiesand> (4): I don't think this would have to happen before we branch?
[14:34:48] <kaduk> I think you're right, in that (4) does not strictly need to happen pre-branch.
[14:35:16] <Jeffrey Altman> Changing the meaning of -S -M -L has been contentious in the past because it results in a potentially incompatible set of config values being used when they are mixed with other command line options
[14:36:00] <kaduk> It's not something I would want to change within a stable release branch, certainly.
It seems plausible to do at a new major version.
[14:36:11] <Jeffrey Altman> I believe the config values should be decided before final 1.8.   they can change during pre-release testing
[14:36:26] <kaduk> I agree.
[14:37:37] <kaduk> (5) configure for pam/kauth
Chas proposes dropping the pam sources entirely.  I think I'm more comfortable doing that on master post-branch than pre-branch.
There didn't seem to be any objection to removing the --enable-pam knob and making the kauth knob control that functionality.
[14:37:48] <Jeffrey Altman> the problem is that if you bump -L to mean set X, Y, Z to something large and then follow on parameters set Y and Z to something too small to support X there is a problem.  There are parameter combinations today that will result in badness.
[14:38:50] <wiesand> So when you run a fileserver, you have to read the manpage... no change?
[14:38:57] <Jeffrey Altman> A precursor for a redefinition of -S -M -L might be adding sanity checks will will itself require an audit
[14:38:59] <kaduk> I would expect anyone considering deploying a new major version to do some testing before rolling it out in production, especially if they have custom tuning.
[14:39:37] <kaduk> We can be sure to put an entry in the release notes that their meaning has changed.
[14:41:27] <Jeffrey Altman> My experience with the 1.2 to 1.4.to 1.6 transition tells me otherwise.   Many sites just copy the same config across all of their servers regardless of version of the server or how it is being used.
[14:42:27] <Jeffrey Altman> and sites look at other sites configurations from workshop presentations or even bos status output and just clone it
[14:42:35] <kaduk> What would you have us do, then?  Change the documentation for -L to indicate that it is for historical compatibility and should not be used?
[14:44:24] <meffie> how about new options, maybe -X, and log warnings when -L is used, like andrew did for des?
[14:44:41] <kaduk> "Not that the people doing this will read logs, of course."
[14:45:58] <wiesand> Has this been on the roadmaps shown?
[14:46:34] <kaduk> I don't remember it being brought up until a few weeks ago.
It is possible that I have not been paying attention in the right places, though.
[14:47:02] <wiesand> Same here.
[14:47:16] <meffie> i recall discussions at workshops.
[14:48:03] <wiesand> Looks a bit like an artifical delay of 1.8 to me.
[14:49:53] <Jeffrey Altman> There were discussions of how to do configuration redesign as part of a move to a new configuration format.   The new configuration format work has not been implemented for OpenAFS.
[14:50:13] <Jeffrey Altman> The most recent discussion was at the Pittsburgh hackathon
[14:53:41] <wiesand> IMHO, this belongs on a feature wish list, not on the list of prerequisites for 1.8.
[14:54:16] <Jeffrey Altman> I don't think 1.8 should block on configuration changes.   I agree that a concrete proposal to openafs-info should be made in order to obtain feedback.  The problem of course is that few end user organizations actually read openafs-info or will provide feedback.
[14:55:38] <kaduk> "1.8 should not block on configuration changes", okay.
Probably we should move on for now, then.
[14:55:49] <kaduk> (Anything to say about the configure pam/kauth thing?)
[14:56:22] <wiesand> I forgot why this has to change at all, sorry.
[14:56:50] <Jeffrey Altman> my personal belief is that pam modules are an upstream distribution decision and should not be in the OpenAFS tree.
[14:56:55] <kaduk> It doesn't strictly speaking have to change.
Just, the pam module is pretty dumb in this day and age, and you shouldn't be using it.
[14:57:13] <Jeffrey Altman> The only pam module in the OpenAFS tree is one that you wouldn't want to use
[14:57:26] <kaduk> I guess maybe we should ask Daria for any input about the IBM agreement side of things?
[14:58:41] <wiesand> Again, unless there's work in progress that's close to final, I'd put it on the wish list for 2.0, or whatever.
[14:59:04] <wiesand> My 2c worth.
[14:59:44] <kaduk> I guess I can't really counter that.
The main motivation for looking was basically that we have a lot of configure options, probably too many.  But that's not particularly timely.
[15:00:30] <kaduk> And that same argument holds for the other configure knobs in item (6), so I won't mention them here, other than to note that we seem to have agreement to default to --enable-pthreaded-ubik for 1.8 (already in gerrit).
[15:01:16] <wiesand> Fine, if it's believed to be ready.
[15:01:32] <kaduk> (It's like a one-line patch.)
[15:01:32] <Jeffrey Altman> pthreaded ubik requires extensive testing
[15:02:04] <wiesand> 1.8 will undoubtedly require extensive testing...
[15:02:46] <Jeffrey Altman> If pthreaded ubik is going to be used in 1.8 then it should default to on in order to make sure that it is tested.
[15:03:10] <kaduk> I can't tell; are we in agreement?
[15:03:43] <Jeffrey Altman> Ben, I believe that you and I are in agreement.  I'm not sure about the rest.
[15:04:08] <meffie> yes, it should be default imo
[15:04:11] <kaduk> Well, I think we can add Chas to the two of us.
And I don't think I've seen anyone support the contrary opinion...
[15:04:55] <wiesand> To make a more precise statement: If it's implemented, and there's no known problem with it that couldn't be sorted out quickly, including it in 1.8 is fine.
[15:06:27] <Jeffrey Altman> If there is a problem, sorting it out is unlikely to be done quickly
[15:07:31] <kaduk> Heck, the hypothetical problem itself is unlikely to appear quickly.
[15:08:27] <wiesand> When it does, lwp is still an option?
[15:08:57] <Jeffrey Altman> If you build from source.
[15:10:52] <kaduk> A sufficiently clever packager might be able to provide a different binary package, but it would probably be a lot of work.
[15:12:24] <wiesand> I think my packages still have lwp versions of fileserver, volserver, and butc ;-)
[15:12:48] <Jeffrey Altman> because the servers are renamed
[15:13:07] <wiesand> Sure.
[15:13:09] <meffie> i thought just dafs was renamed?
[15:13:43] <Jeffrey Altman> I don't think wiesand has lwp fileservers.   I think he has dafs and non-dafs
[15:14:16] <wiesand> I think I have dafs, non-dafs and non-dafs lwp.
[15:14:34] <meffie> interesting.
[15:14:34] <wiesand> Haven't tried them in a long time though.
[15:14:37] <Jeffrey Altman> how do you have two binaries in the package with the same name?
[15:14:56] <wiesand> I don't.
[15:15:20] <meffie> did you rename the lwp fileserver?
[15:15:32] <wiesand> Yes. It's really just a fallback.
[15:15:47] <wiesand> Back from the days when someone warned me about the pthreaded servers.
[15:16:12] <wiesand> Never needed them, except once for running servers under usermode linux. Pretty exotic.
[15:16:32] <wiesand> But packaging them like this is pretty simple.
[15:17:01] <Jeffrey Altman> that makes me really sad because the existence of lwp volservers in the wild seriously impact the ability to improve performance of volume operations
[15:18:05] <wiesand> It takes manual work to actually use these binaries. They're just there for worst case scenarios.
[15:18:12] <wiesand> And I should probably drop them.
[15:18:22] <Jeffrey Altman> you should remove them from your packaging
[15:18:32] <Jeffrey Altman> do we even build lwp fileservers on master?
[15:18:38] <meffie> no
[15:19:31] <kaduk> Hmm, my self-review noted an issue with 'make dest' and shared libafsrpc.  Namely, the current patch in gerrit doesn't have one.  (I mean, master doesn't, either, but...)  1.6 does provide a shared libafsrpc from 'make dest'.
[15:20:09] <kaduk> I think I am probably willfully ignorant of 'make dest' and in particular what support of support expecation there is for its continued existence and functionality.
[15:21:18] <Jeffrey Altman> its going to be the sites that build out of tree things that will care.   CMU for example.
[15:21:42] <wiesand> Is transarc path support another AFS trademark issue?
[15:21:53] <Jeffrey Altman> no
[15:22:30] <kaduk> I'm curious how "build out of tree things" implies a need for make dest (or similar), but perhaps this is not the place/time to enlighten me.
[15:23:07] <wiesand> Ben: the shlib is built when you "configure; make; make install" ?
[15:23:16] <kaduk> Yes.
[15:23:19] <meffie> (i'll be sad to see make dest go, i tend to use that a lot for testing)
[15:23:35] <wiesand> Well, fix it ;-)
[15:23:42] <kaduk> Well, make dest will still succeed and give you a static library...
[15:25:06] <Jeffrey Altman> My point is that the use of the shared libraries is most likely by out of tree things.  I don't know those sites are building things.   Don't they "make dest" with the object tree redirected outside the source tree and then use that output directly?
[15:25:08] <wiesand> make install DESTDIR=... should be a replacement for your testing use case?
[15:25:33] <meffie> yes
[15:25:52] <kaduk> I don't know how those sites are building things, either.
[15:26:05] <wiesand> Doesn't look like a showstopper to me.
[15:26:15] <kaduk> I'm more asking, do we as a project feel that we need to support the continued functionality of 'make dest' as it has historically worked.
[15:28:11] <kaduk> It sounds like Stephan's answer is "no".
[15:28:46] <kaduk> (My answer is also "no", because I haven't really managed to be convinced of what it's good for.)
[15:29:37] <wiesand> I've been using it forever. But I'm sure I can cope.
[15:29:53] <Jeffrey Altman> I wish Daria would say something.
[15:30:11] <kaduk> Sometimes her client silently fails to actually send...
[15:30:20] <Jeffrey Altman> I pinged her privately
[15:30:26] <Jeffrey Altman> no answer there either
[15:31:29] <wiesand> But is this something that would be much harder to fix between two 1.6.8preN than before creating the branch?
[15:32:22] <kaduk> If we branch without this functionality and later discover that we really do need it, I don't think that the changes needed to add it will be too disruptive for inclusion between preNs.
[15:32:59] <kaduk> (It would be localized to just the one Makefile in question.)
[15:33:03] <Jeffrey Altman> It won't be a code change.
[15:33:10] <Jeffrey Altman> a build system change
[15:33:22] <Jeffrey Altman> Simon, says to kill it off
[15:33:29] <kaduk> Yay!
[15:35:33] <meffie> i'll need to make an alias for my muscle memory :)
[15:35:49] <kaduk> Only if you are using the shared library from your test builds?
[15:36:02] <kaduk> Unless Simon is making a stronger statement than I interpret.
[15:38:08] <wiesand> More items?
[15:38:54] <wiesand> It's getting late here, and I missed lunch today... ;-)
[15:38:54] <kaduk> Just the obligatory begging and pleading for documentation updates and review of gerrit changes, I think.
[15:39:37] <kaduk> It's almost lunch time here, and you're several hours ahead -- go eat!
[15:40:23] <wiesand> Well, I'm not going to starve ;-)
[15:40:26] <Jeffrey Altman> The dog needs to be walked
[15:40:38] <Jeffrey Altman> I'm on borrowed time
[15:40:59] <wiesand> So, let's call it a day.
[15:41:08] <wiesand> Thanks a lot everyone!
[15:41:28] wiesand leaves the room
[15:41:40] <Jeffrey Altman> good bye
[15:41:52] Marc Dionne leaves the room
[15:43:01] meffie leaves the room
[15:54:57] <shadow@gmail.com/barnowlE5B64A04> make dest needs to die but packaging will be sad
[15:56:58] <kaduk> Thinking more reminds me that an argument for the utility of make dest related to installing things into a subdirectory with the corresponding sysname, as would potentially be used by the upserver.
Maybe "remove upserver" should be on the todo list :)
[16:03:54] <shadow@gmail.com/barnowlE5B64A04> upserver needs to die or be drastically rethought
[16:04:12] <kaduk> Before or after 1.8?
[17:04:51] deason leaves the room
[18:41:14] <kaduk> I've seen IRC and zephyr reports that the "getcwd" bug is back in 1.6.10pre1.
[18:42:23] <kaduk> (RT 131780 or similar)
[18:43:31] <Jeffrey Altman> The reporters should test the 3.17 changes especially if they are using the most recent RHEL kernel
[18:44:00] <kaduk> The zephyr folks are on a fedora kernel, presumably most recent.
[18:44:15] <kaduk> I'll have to look at IRC scrollback, but don't think they gave a version.
[18:49:00] <kaduk> scripts.mit.edu would probably be willing to do so.  I know less about this guy on IRC.
[19:08:48] <kaduk> (Anders says that the commit messages for the 3.17 changes make them sound like they're no-ops on 3.16 kernels, which is what they're currently running.)
[19:13:29] <Jeffrey Altman> they are no-ops if they are using pure 3.16 kernels.  the rhel kernels are not pure.
[19:13:47] <Jeffrey Altman> I don't know about Fedora
[19:14:18] <kaduk> Oh, and the IRC guy is on debian wheezy, it sounds like.
So ... I'm not sure what's up with his kernel.
[19:40:19] shadow@gmail.com/barnowlE5B64A04 leaves the room
[19:40:28] shadow@gmail.com/barnowlE5B64A04 joins the room
[19:45:45] shadow@gmail.com/barnowlE5B64A04 leaves the room
[19:45:52] shadow@gmail.com/barnowlE5B64A04 joins the room
[22:01:00] kaduk leaves the room