Home
release-team@conference.openafs.org
Wednesday, May 7, 2014< ^ >
Room Configuration
Room Occupants

GMT+0
[00:05:36] stephan.wiesand joins the room
[00:18:23] stephan.wiesand leaves the room
[04:30:06] shadow@gmail.com/barnowl7628413F joins the room
[10:35:51] wiesand joins the room
[10:37:53] <wiesand> test
[12:32:46] meffie joins the room
[13:59:13] kaduk joins the room
[14:01:22] <kaduk> mornin'.
[14:01:31] <wiesand> Good afternoon/
[14:01:55] deason joins the room
[14:02:02] <deason> hi
[14:03:03] <wiesand> We probably need Marc for a meaningful discussion about 1.6.8?
[14:03:59] <wiesand> Does anyone else know the story about RT 131855 / gerrit 11118 ?
[14:04:23] Marc Dionne joins the room
[14:04:34] <wiesand> Ah :) Hi Marc!
[14:04:39] <Marc Dionne> Hi Stephan
[14:05:03] <kaduk> "I think Marc knows about that ticket/change"
[14:05:33] <wiesand> Hi Marc, can you update us on RT 131855 / gerrit 11118?
[14:06:11] <Marc Dionne> well 131855 was created based on some assumptions, but the real issue turned out to be what's in 11118
[14:06:26] <deason> I'm not sure what you want to hear; there's a potential/probably fix that's getting reviewed
[14:06:49] <deason> er, "probable", or "certain" (I haven't looked much yet)
[14:06:55] <Marc Dionne> 131855 needs its subject fixed to match the actual problem
[14:07:20] <wiesand> Is that a recent regression?
[14:07:30] <Marc Dionne> no, i think it's an old bug
[14:08:08] <wiesand> In that case, releasing pre2 as is as 1.6.8 seems an option. Thoughts?
[14:09:16] <kaduk> It's certainly an option.  11118 doesn't look terribly invasive, though, so I think including it is also an option.
[14:10:01] <wiesand> It would call for a pre3.
[14:10:38] <deason> yes, releasing as 1.6.8 seems like an option; with providing warnings about the known issues
[14:11:18] <wiesand> Known issues = 11118 and the Heimdal on Unix problem?
[14:11:26] <kaduk> Do we want to try to catch up to the fast pace of the 1.7 releases? :)
[14:11:54] <wiesand> You think it's too early for 1.6.8?
[14:12:16] <deason> known issues: yeah
[14:12:16] <wiesand> 1.6.7 was security-only, and even that was more than a month ago.
[14:12:16] <kaduk> Not necessarily.
[14:13:06] <wiesand> Proposal:
[14:14:08] <wiesand> We have more pre binaries (EL7 rc and SuSE). Announce those on -info today, ask for one more week of testing, and release next Wednesday if no new issues are found.
[14:14:51] <wiesand> (barring Linux-3.15 issues and test results gathered by Andrew) - anything?
[14:16:03] <wiesand> Marc, would it make you sad if we defer 11118 to 1.6.9?
[14:17:18] <wiesand> ping?
[14:17:19] <Marc Dionne> not necessarily - i think they removed -fakestat-all from their config anyway, but i should ask if the reporter cares
[14:17:33] <deason> the only concern I can think of is that leaving in the 11118 issue is leaving in a consistency bug, which is potentially pretty serious
[14:17:47] <deason> er, cache consistency, though only in a very specific way, and has a workaround
[14:18:00] <deason> but if people want to avoid it, they'd have to accept the downsides of non-fakestat
[14:18:33] <Marc Dionne> do most people run with -fakestat, or -fakestat-all
[14:18:41] <wiesand> The issue is fakestat-all only?
[14:18:48] <Marc Dionne> no, also -fakestat
[14:18:48] <wiesand> We run with -fakestat.
[14:18:56] <deason> yes, I think most people run with some form of it
[14:19:00] <Marc Dionne> but then it only affects files at the root of the cell
[14:19:04] <deason> though with plain -fakestat, you're way less likely to encounter it
[14:19:18] <Marc Dionne> yes exactly
[14:19:35] <wiesand> And with -fakestat -dynroot, you're safe?
[14:20:00] <wiesand> Ah, no.
[14:20:06] <Marc Dionne> no i think you still have the problem
[14:20:10] <deason> but some people can have some strange mounting (traversing different cells), and iirc at least in the past having a localcell:vol mount may have invoked regular -fakestat
[14:21:25] <deason> I'd say it's certainly not widespread/common for normal usages, but in some environments it could be more relevant
[14:21:38] <deason> but it's probably existed for a long time
[14:22:09] <Marc Dionne> probably since fakestat was added - saw a very similar bug report on openafs-info from 2008
[14:22:33] <deason> link?
[14:23:03] <wiesand> The reporter was Rich from nd?
[14:23:15] <Marc Dionne> not that old one, no.  give me a sec
[14:23:28] <wiesand> But the new one, right?
[14:23:36] <Marc Dionne> yes
[14:24:27] <Marc Dionne> http://lists.openafs.org/pipermail/openafs-info/2008-March/028794.html , similar but not exactly the same - seemed worse at the time
[14:24:44] <wiesand> Asking him whether he'd have a problem with deferring the fix to 1.6.9 would be good.
[14:24:59] <Marc Dionne> will do, yes
[14:26:08] <wiesand> Thanks. And I'm inclined to base the decision on his answer.
[14:27:43] <wiesand> Andrew, did you gather any test results from the volunteer group?
[14:28:27] <wiesand> Marc, any dark clouds regarding Linux-3.15?
[14:28:40] <Marc Dionne> we're still good as of this morning
[14:28:51] <deason> nah, just a couple of responses suggesting they were going to deploy something
[14:28:53] <wiesand> Thanks.
[14:30:35] <wiesand> Ok. Let's ask Rich and see.
[14:30:52] <Marc Dionne> i asked - will let you know when i get a response
[14:31:53] <wiesand> Thanks. If he's ok with it, we'll defer. Otherwise, we'll release pre2 as 1.6.8 and start working on 1.6.9. If there are objections or strongly different preferences, please voice them now :-)
[14:32:13] <wiesand> Er, you got it...
[14:32:48] <wiesand> (either defer and release pre2 as is, or have a pre3 with 11118)
[14:34:08] <wiesand> On to "other problem reports"?
[14:35:06] <wiesand> I whipped up gerrit 11128 for the depmod issue.
[14:35:19] <kaduk> Like those duplicates about immutable /usr on rpm-based systems?
[14:35:43] <wiesand> That's on e of them, yes.
[14:35:48] <kaduk> How big a disruption would it be if the rpm packaging switched away from the transarc paths to something more FHS-y?
[14:36:16] <Jeffrey Altman> big
[14:36:17] <wiesand> Would be a no-go in my environment.
[14:37:04] <deason> but with compat symlinks? even so it doesn't seem like something to change in the middle of the release series
[14:37:46] <wiesand> Not without compat symlinks, and probably not even then.
[14:38:21] <kaduk> deason: "middle of the release series" meaning OpenAFS 1.6.x, or RHEL 6.x, or ...?
[14:38:22] <deason> I meant "it's really such a problem even with symlinks?"
[14:38:36] <deason> I meant openafs 1.6.x
[14:38:44] <wiesand> Doing it for EL >= 7 and Fedora >= 21 would be an option.
[14:39:06] <deason> oh okay, doing it that way is an option
[14:39:25] <wiesand> It's more mess in the spec though, and some real work.
[14:39:57] <deason> would splitting into a separate spec file at some point make some of this any easier?
[14:40:30] <wiesand> Not in the long run.
[14:41:24] <kaduk> "long run" meaning "when the old systems finally die"? ;)
[14:41:34] <wiesand> The depmod thing is straightforward. We should fix that in 1.6.9 or 1.6.8pre3.
[14:41:45] <wiesand> EL6 is not ging to die for six years.
[14:42:36] <wiesand> But moving configuration directories around is another story.
[14:42:59] Simon Wilkinson joins the room
[14:43:12] <wiesand> /usr/vice/etc -> /etc/openafs-client seems like a choice.
[14:43:28] <wiesand> But what would we do about /usr/afs/local and /usr/afs/etc ?
[14:43:57] <Simon Wilkinson> We thought about making the change 1.4 -> 1.6 and chickened out
[14:44:12] <deason> there are precedents in other rpm packaging, and debian
[14:44:15] <deason> just follow one of them
[14:44:20] <wiesand> I'd reconsider it for 1.6 -> (next stable).
[14:44:23] <Marc Dionne> stephan, i'm reminded that rich at nd has also seen a kernel oops with 1.6.8pre2 - but not 100% clear it's related to openafs yet, or if it is, whether it's something new to 1.6.8
[14:44:29] <Simon Wilkinson> There is RPM packaging available that does do things the FHS way. I think the way to do it would be to just retire our packaging and use someone elses.
[14:44:58] <wiesand> Ken's?
[14:45:12] <Simon Wilkinson> Yeah, the RPM Fusion stuff.
[14:46:20] <wiesand> Because the other's I know do things with the kernel modules not approved by the experts ;-)
[14:46:57] <wiesand> But I really can't imagine that in the 1.6.x series.
[14:47:22] <Simon Wilkinson> No, I don't think we can change things like that mid way through 1.6.x
[14:47:47] <deason> well, it's one thing to change it for everyone in the middle of 1.6.x, but another to just start doing it for rhel7, a platform that is not yet released
[14:48:14] <kaduk> Coming at this from the Debian and FreeBSD worlds, it seems strange that the paths of things in the packaging is seen as something that upstream (us) cares about -- in those worldviews, the paths of configuration files are solely the concern of the OS packaging, and can be changed independently.
[14:48:33] <Simon Wilkinson> And then you have to maintain two sets of packaging? One for RHEL7, one for everybody else?
[14:48:43] <deason> kaduk: that's because in this case, upstream is also the downstream packagers for these rpms
[14:48:52] <deason> which is crazy in my opinion, yes
[14:49:08] <wiesand> Simon: no, more %if's  in the spec
[14:49:34] <deason> well, either more %ifs or separate files, whatever; yes it means more things to maintain for a while
[14:49:51] <deason> but everything could also be transitioned to non-transarc paths for post-1.6
[14:50:03] <Simon Wilkinson> And I think the ship has sailed for RHEL7 in any case, unless we could do it _really_ _really_ quickly
[14:50:06] <deason> or just delay everything to post-1.6; I'm not pushing for either way, really
[14:50:33] <wiesand> ETA for RHEL7 is... August?
[14:50:50] <kaduk> "delay everything to post-1.6" may have the "feature" of getting lots of testers for the next stable release branch ;)
[14:51:07] <kaduk> I did not think that an ETA for RHEL 7 was public information.
[14:51:16] <wiesand> It isn't.
[14:51:32] <wiesand> That's an estimate based on RHEL5/6 history.
[14:51:51] <wiesand> Six months public beta, then two months to the release.
[14:51:59] <kaduk> Ah.
[14:52:29] <wiesand> But yes, I could be completely wrong.
[14:54:21] <wiesand> Just using RPMfusion for future {OpenAFS,RHEL,Fedora} releases would boil down to no longer providing packages ourselves?
[14:54:55] <deason> yes, probably
[14:55:04] <wiesand> We could do that very very quickly ;-)
[14:55:14] <deason> we could still provide a repository maybe, but maintenance of the packaging is done by not-us
[14:55:24] <deason> even if it's done by people in this room, not by "openafs"
[14:55:48] <deason> but done by "epel" or "fedora" or "rpmfusion" or whatever
[14:56:06] <wiesand> EPEL and Fedora won't.
[14:56:19] <deason> but I could see some motivation if someone wanted a repository just for openafs stuff, but not adding all of rpmfusion
[14:56:24] <deason> I know, just giving examples of downstreams
[14:56:54] <Simon Wilkinson> There is the possibility of getting the fileserver and client utilities into Fedora. But we couldn't get the kernel module in there.
[14:57:04] <Simon Wilkinson> Although Fedora has started shipping kmodtool, apparently.
[14:57:40] <deason> yes, I just glanced at ken's comment in 131862; I wasn't clear if that kmodtool has any relevance to us?
[14:58:13] <Simon Wilkinson> Currently, we use our own, because there didn't use to be one available on Fedora.
[14:59:16] <wiesand> The one in RHEL assumes you can build the module against the GA kernel and uses for all fututre ones.
[14:59:36] <wiesand> Which is proven to almost, nut not quite, work for the openafs module.
[14:59:41] <Simon Wilkinson> Yeah, it assume that everything you are using is on the kabi whitelist
[14:59:49] <Marc Dionne> only kmodtool i see is from rpmfusion, not fedora
[15:01:33] <wiesand> I'll look at what Ken does, and how feasible it is to use the same layout for RHEL7 and F21+ before the RHEL7 release.
[15:02:20] <wiesand> We can then discuss this further during the 1.6.9 cycle.
[15:03:06] <wiesand> And maybe there'll be some feedback to the minutes.
[15:03:33] <wiesand> More thoughts on this, or anything else to discuss today?
[15:04:03] <Marc Dionne> did you see my earlier comment about another bug at ND?
[15:04:18] <wiesand> I did, thanks.
[15:04:39] <Marc Dionne> ok, just wanted to make sure you were aware of it
[15:04:55] <wiesand> But a single oops with no evidence that it's a 1.6.8 regression wouldn't make me delay 1.6.8 much more at this point.
[15:05:25] <deason> I saw something with a bunch of stack dumps with lock_rename in them; are you talking about something else?
[15:06:08] <Marc Dionne> no that's what I'm talking about, i think.  looks like looping within d_ancestor
[15:06:45] <wiesand> Must have missed that one.
[15:07:07] <deason> the things I'm looking at has rip in d_ancestor by they mention some rename stuff in the stack
[15:07:13] <deason> er, 'but they mention'
[15:07:39] <Jeffrey Altman> deason: this is the same
[15:07:50] <Marc Dionne> yes the stacks i was also involve rename
[15:07:50] <deason> I thought it was just the known rhel multiple-mounts thing, since there's an earlier warning about d_splice_alias
[15:09:08] <Marc Dionne> didn't see any d_splice_alias warning, but yes, likely related
[15:09:43] <deason> but nothing further needed here unless there's more info
[15:10:05] <deason> wiesand: did you want to discuss versioning/branching stuff here, or let it be on the list for a while?
[15:10:25] <wiesand> Discussing it here didn't work.
[15:10:49] <Jeffrey Altman> while we have the group we can discuss it but the discussion should move to the "openafs" room
[15:10:54] <wiesand> And there's activity on the list.
[15:11:41] <wiesand> Moving over to openafs is fine by me.
[15:12:53] <wiesand> So let's call this a meeting. Thanks a lot everyone. See you in the openafs room ;)
[15:12:59] <Jeffrey Altman> I believe that releasing 1.6.8 at this point is reasonable.   We waited to determine if the getcwd patches were a problem and they aren't.    
[15:13:14] <Jeffrey Altman> switching rooms
[15:13:19] <wiesand> Ok. Thanks.
[15:13:28] <meffie> ok, thanks.
[15:13:42] meffie leaves the room
[15:20:18] deason leaves the room
[16:26:55] wiesand leaves the room
[21:01:42] Simon Wilkinson leaves the room
[21:03:06] Simon Wilkinson joins the room
[21:22:38] kaduk leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!