- Wednesday, May 4, 2016

release-team@conference.openafs.org

Wednesday, May 4, 2016< ^ >

Room Configuration

Room Occupants

GMT+0
[00:26:05] jhutz@jis.mit.edu/owl leaves the room
[00:29:35] jhutz@jis.mit.edu/owl joins the room
[02:00:10] mvita leaves the room
[02:10:46] mvita joins the room
[03:35:59] mvita leaves the room
[11:17:02] mvita joins the room
[11:38:46] mvita leaves the room
[11:44:51] meffie joins the room
[13:31:48] mvita joins the room
[14:00:11] wiesand joins the room
[14:00:32] <wiesand> Hi
[14:01:44] <wiesand> Anyone here?
[14:03:03] <Jeffrey Altman> I am.
[14:03:18] <wiesand> Hello Jeff
[14:03:30] <Jeffrey Altman> Hello Stephan
[14:04:41] <wiesand> It still seems this will be a very brief meeting ;-)
[14:05:36] <Jeffrey Altman> May I ask a question about the proposed announcement text for 1.6.18?
[14:05:41] <wiesand> Sure
[14:07:31] <Jeffrey Altman> The bullet "Basic support for the latest OSX ... release".  As an end user I am likely to interpret that as meaning that if I check out this release from the repository that I should be able to build a working installer.  Is that what this bullet means or were there simply additional commits that bring OpenAFS closer to support for El Capitan.
[14:08:54] <wiesand> "OS X Support" has for a while now been limited to building the binaries etc., not the installer, hasn’t it?
[14:09:24] <Jeffrey Altman> The only commit I see on the branch is 848eb258e961b4bd5ee3181b53cc08e3308d95a2 which is not sufficient to build packaging for El Capitan
[14:10:08] <mvita> sorry, we were stuck on another call.
[14:10:26] <wiesand> Jeff: right.
[14:10:29] <Jeffrey Altman> In one of the prior releases there was a similar bullet that resulted in someone trying to build El Capitan packages and failing.
[14:11:33] <Jeffrey Altman> Perhaps change the bullet to
   Support for building OS X El Capitan binaries (still no packaging)
[14:12:02] <wiesand> I was about to ask... yes, good point.
[14:12:47] <wiesand> NB we have a a packaging change in 12239
[14:13:23] <wiesand> I just failed to draw anyone’s attention to it despite mentioning it in the invitation several times.
[14:14:30] <mvita> sorry, Stephan, didn't have a chance to read your invite yet, I'm scrambling this morning.
[14:14:38] <wiesand> And even if that would allow building an installer, could that actually be used without either being a registered developer or doing some nasty things?
[14:14:54] <wiesand> Mark: I know how you feel
[14:15:47] <Jeffrey Altman> There are end user organizations that have the required kernel extension signing certificates.
[14:15:48] kadukoafs@gmail.com/barnowl5B83EB95 leaves the room
[14:15:48] kadukoafs@gmail.com/barnowl5B83EB95 leaves the room
[14:15:48] kadukoafs@gmail.com/barnowl5B83EB95 leaves the room
[14:16:17] kadukoafs@gmail.com/barnowl93AC7D46 joins the room
[14:16:27] <Jeffrey Altman> They build for themselves but are unwilling to distribute outside their organization.
[14:16:45] <kadukoafs@gmail.com/barnowl93AC7D46> Maybe I can send now?
[14:16:53] <mvita> ACK
[14:16:55] <meffie> hello
[14:16:56] <wiesand> Yes you can
[14:17:11] <Jeffrey Altman> Hi Ben
[14:17:14] <kadukoafs@gmail.com/barnowl93AC7D46> > failed to draw anyone's attention to it
"The diffstat was too scary for the amount of brainpower I had"
[14:18:28] <wiesand> Almost all of this is OS X specific and can’t possibly make things worse. The rest is very small and simple.
[14:19:16] <wiesand> So, I’d still like to get in - but now it’s 1.6.18.1
[14:20:22] <kadukoafs@gmail.com/barnowl93AC7D46> sorry
[14:20:46] <wiesand> No problem.
[14:21:43] <Jeffrey Altman> David Botsch should review it
[14:21:58] <Jeffrey Altman> since he is building OSX for Cornell
[14:22:39] <wiesand> Sent an invitation via gerrit
[14:23:21] <wiesand> So, about a possible 1.6.18.1...
[14:23:46] <wiesand> Ben, do you think what you lined up in gerrit for Linux 4.5 will suffice?
[14:24:34] <kadukoafs@gmail.com/barnowl93AC7D46> "Be careful running this, as I have only proved it correct, not tested
it."
[14:25:07] <kadukoafs@gmail.com/barnowl93AC7D46> This version actually builds, at least (apparently we default to
building for the running kernel and not the installed one, which is
different from FreeBSD).
[14:26:02] <wiesand> You can have any number of kernels installed at the same time...
[14:26:27] <wiesand> So on Linux this has been the default ~forever
[14:27:05] <kadukoafs@gmail.com/barnowl93AC7D46> Yeah, but isn't there a /usr/src symlink or something?
(Anyway, not actually important.)
[14:27:50] <wiesand> Depends on the distro. And has no bearing on which kernel will be booted next time.
[14:28:06] <wiesand> Linux is all about choice ;-)
[14:28:18] <kadukoafs@gmail.com/barnowl93AC7D46> Regrettably, yes.
[14:29:02] <kadukoafs@gmail.com/barnowl93AC7D46> Anyway, I'm about to go poof.
[14:29:13] <kadukoafs@gmail.com/barnowl93AC7D46> But feel free to talk about what progress has been made on the list of
things I sent last week ;)
[14:29:58] <wiesand> So, what’t the general opinion on targetting a 1.6.18.1 with Linux 4.5 support, and maybe the OS X packaging change?
[14:30:04] <wiesand> Ben: ok ;-)
[14:30:17] <kadukoafs@gmail.com/barnowl93AC7D46> I've been trying to work through the +0/+1 changes and do another
round of triage; there's a few more potential blockers hiding there.
[14:30:33] <kadukoafs@gmail.com/barnowl93AC7D46> Like 11988, 11793
[14:30:54] <kadukoafs@gmail.com/barnowl93AC7D46> 1.6.18.1 like that sounds reasonable
[14:31:05] <wiesand> Thanks
[14:31:16] <mvita> agreed
[14:31:44] <wiesand> Ben: when you find the time, could you tag a854188922f29fac15ad17999732c45b7e6818bf as openafs-stable-1_6_18 ?
[14:31:56] <kadukoafs@gmail.com/barnowl93AC7D46> later today, probably
[14:32:26] <wiesand> Thanks. No hurry, given the delay already cause by me.
[14:33:56] <wiesand> Is anything major coming up for a 1.6.19 ?
[14:34:19] <meffie> not that i know of.
[14:36:13] <meffie> marcio and i recently looking at some issues around afsd + systemd, which could be relevant for 1.6.x
[14:36:23] <wiesand> So we should just pick fixes from master if they seem worth the effort.
[14:36:38] <wiesand> Ah, ok. What kind of issues?
[14:37:25] <wiesand> We run the client on quite a few EL7 systems, no issues known
[14:38:43] <meffie> some problems reported about having multiple afsd processes
[14:39:14] <meffie> i'll know more soon i hope. :)
[14:39:32] <wiesand> That probably wouldn’t work well. Looking forward to the details.
[14:39:42] <mvita> stephan, do you run those RH7 afsd clients w/ systemd unit files?
[14:39:48] <wiesand> Yes.
[14:39:55] <mvita> and are they running -afsdb option?
[14:39:55] <wiesand> SL packaging
[14:40:31] <wiesand> -afsdb -dynroot-sparse -fakestat
[14:40:35] <mvita> tx
[14:40:42] <meffie> thank you.
[14:41:30] <wiesand> Even more curious now ;-)
[14:41:47] <mvita> well, systemd wants to know which pid is the client
[14:42:03] <mvita> if you specify -afsdb, then a userspace thread sticks around
[14:42:15] <mvita> otherwise, everything is kernel threads
[14:42:46] <meffie> yes, we trick systemd into using the afsdb daemon. sad.
[14:43:34] <wiesand> Ah. Thanks.
[14:44:35] <Jeffrey Altman> there are other reasons that userland threads stick around, at least on master.
[14:44:56] <mvita> well, -rmtsys will do it
[14:45:02] <mvita> what other ones, Jeffrey?
[14:45:09] <Jeffrey Altman> cache manager key tabs
[14:45:20] <mvita> oh, haven't encountered that one, thanks
[14:45:28] <meffie> yes, there are some others.
[14:46:05] <meffie> -afsdb is just the most common one.
[14:46:52] <wiesand> This may require Type=oneshot in the unit file?
[14:47:39] <meffie> not sure yet.
[14:48:08] <wiesand> Or always keep a userland thread around. Who cares?
[14:48:58] <wiesand> That would be a 1.6.19 change. We ship no unit files...
[14:49:06] <meffie> yes, that is what i'm looking into. it can restart the afsdb process when it crashes.
[14:49:48] <wiesand> afsdb or afsd?
[14:50:16] <wiesand> Not sure I’ve ever seen a crashed afsd that could be restarted.
[14:50:21] <meffie> i think currently people use -afsdb and systemd type "forking".
[14:50:27] <Jeffrey Altman> why is it crashing?
[14:50:35] <wiesand> Mike: that’s what we do.
[14:51:15] <meffie> it was a bug in the os that caused afsdb process to crash.
[14:51:41] <mvita> libnss, iirc
[14:52:57] <kadukoafs@gmail.com/barnowl93AC7D46> I think debian uses something other than oneshot, let me look
[14:54:52] <kadukoafs@gmail.com/barnowl93AC7D46> Per
http://anonscm.debian.org/cgit/pkg-k5-afs/openafs.git/tree/debian/openafs-client.service
we have RemainAfterExit=true, which is the more-supported way to get
systemd to think we're still running
[14:55:21] <meffie> and with afsd -afsdb on?
[14:55:37] <kadukoafs@gmail.com/barnowl93AC7D46> I think so
[14:55:47] <meffie> ok, thanks.
[14:56:29] <wiesand> It runs like this on my Ubuntu test system
[14:56:55] <kadukoafs@gmail.com/barnowl93AC7D46> We have a lot of logic "to handle" the case where you 'apt-get install
openafs-client openafs-modules-dkms' so systemd tries to start the
client before there's a module; without jumping through those hoops it
will be marked as disabled for too many errors and it's pretty
confusing to get it back.
[14:59:28] <meffie> oh man.
[15:01:22] <meffie> > it was a bug in the os that caused afsdb process to crash.
i think the offending bug was in an old version of libc, that caused nscd to SIGBUS when it tried to access a bogus region of a mmap.
[15:01:38] <mvita> yeah, very old
[15:01:44] <mvita> rh5 old, I think
[15:02:16] <wiesand> I knew there were more good reasons to get rid of nscd, which we did a long time ago :)
[15:02:26] <meffie> heh.
[15:04:01] <meffie> my description is a bit off. nscd did not crash, but it caused the processes that were sharing memory via the mmap to crash. anyway, not an afs bug.
[15:04:02] <wiesand> So, on the current 1.8 blockers...
[15:04:26] <wiesand> 11984 or 12262
[15:05:08] <wiesand> 10004
[15:05:13] <kadukoafs@gmail.com/barnowl93AC7D46> I am not very familiar with this code, so anyone should feel free to
take 12262 and run with it (i.e., push a new version on top).
[15:05:41] <wiesand> 11988 and 11793, mentioned by Ben above
[15:05:42] <mvita> I'll do it
[15:05:49] <mvita> 12262, that is
[15:05:58] <mvita> very familiar
[15:06:01] <mvita> ;-)
[15:06:08] <kadukoafs@gmail.com/barnowl93AC7D46> Thanks, Mark.
[15:06:41] <meffie> (i'm not sure why that's a blocker, rather than just another bug?)
[15:06:56] <kadukoafs@gmail.com/barnowl93AC7D46> 11988 is, IIRC, a no-brainer, but the logic is slightly complicated so
I didn't convince myself I understood it last night.
[15:07:13] <kadukoafs@gmail.com/barnowl93AC7D46> Basically, our code is not strict-aliasing safe, so we should be
compiling with -fno-strict-aliasing in the normal case.
[15:08:25] <kadukoafs@gmail.com/barnowl93AC7D46> I guess maybe it does not actually qualify as a "blocker" ... but it's
easy ;)
[15:09:18] <kadukoafs@gmail.com/barnowl93AC7D46> re 11793, I am not sure whether it's worth pulling just that change
out from the rest of the topic, or we want to take the whole topic, or
what.
[15:12:12] <Jeffrey Altman> sorry, I've been pulled away
[15:12:19] <meffie> i put a star on 11793. that will remind me.
[15:13:53] <wiesand> We ran a number of systems with 3ecd65d3 for a while.
[15:13:59] <wiesand> I think so did CERN.
[15:15:12] <kadukoafs@gmail.com/barnowl93AC7D46> I would have to search to remember what the trigger was that prompted
us to decide to revert it, but it is probably some data corruption
issue.
[15:15:22] <wiesand> There was a very real use case in one of the LHC experiments.
[15:16:05] <wiesand> I’m not sure it still exists, and it was a build tool doing fairly sick things.
[15:17:43] <wiesand> It was stat()ing like crazy. When two users were using it on the same node, both instances would become unusably slow.
[15:18:31] <kadukoafs@gmail.com/barnowl93AC7D46> (N.B. that the last commit in the topic seems to be a safe alternative
that is also lockless.)
[15:18:39] <kadukoafs@gmail.com/barnowl93AC7D46> Or, claims to be, at least.
[15:22:20] <wiesand> 11793 will need a nontrivial rebase
[15:23:21] <wiesand> <<<<<<< HEAD
        parent_dv = parent_vcache_dv(parent->d_inode, credp, locked);
=======
        parent = dget_parent(dp);
        pvcp = VTOAFS(parent->d_inode);
        parent_dv = parent_vcache_dv(parent->d_inode, credp);
>>>>>>> af76746... Revert "Lockless path through afs_linux_dentry_revalidate"
[15:23:23] <kadukoafs@gmail.com/barnowl93AC7D46> meep
[15:24:43] <kadukoafs@gmail.com/barnowl93AC7D46> Anyone excited about taking that on?
[15:24:53] <mvita> well, actually, yes
[15:24:57] <kadukoafs@gmail.com/barnowl93AC7D46> (Noting that Andrew is the owner on that set of changes)
[15:25:42] <wiesand> "Meep: The most versatile word in the English language, or in fact any language!" ... I keep learning a lot here ;-)
[15:25:45] <mvita> I'll take it and ask deason if I start treading water
[15:25:51] <kadukoafs@gmail.com/barnowl93AC7D46> And just to double-check, meffie is planning to rebase 10004 and maybe
also do another cleanup commit before it?
[15:26:03] <kadukoafs@gmail.com/barnowl93AC7D46> Thanks again
[15:26:31] <mvita> <takes notes>
[15:26:38] <meffie> yes i have done the cleanup commits, writing commit messages just this morning.
[15:27:30] <meffie> i did not go crazy reorganizing afs_call.c, but it needs it.
[15:29:11] <wiesand> I promised to take care of redhat packaging changes just before my life was disrupted. It’s still on my list.
[15:29:27] <meffie> thank you
[15:29:31] <wiesand> So I’ll fix up 11765. But that’s hardly urgent.
[15:29:51] <kadukoafs@gmail.com/barnowl93AC7D46> excellent :)
[15:30:31] <wiesand> I actually tested 11866 today.
[15:32:00] <wiesand> I’m running out of time.
[15:32:26] <kadukoafs@gmail.com/barnowl93AC7D46> Yeah, it's been a long meeting.
[15:32:36] <kadukoafs@gmail.com/barnowl93AC7D46> But thanks for everything everyone is looking into!
[15:32:57] <wiesand> Thanks for all the work you’re putting in!
[15:32:58] <meffie> excellent, thanks!
[15:33:08] <meffie> yes, thank you
[15:34:35] <wiesand> I’ll send a revised draft with Jeffreys proposed change to -release-team. If there are no more objections to this and the web change, I’ll get 1.6.18 out the door tomorrow.
[15:36:13] <wiesand> I’ll probably be unable to attend June the 2nd
[15:37:03] <wiesand> Datacenter shutdown planned for that time...
[15:37:25] <mvita> okay, thank you.
[15:37:49] <wiesand> I guess we’re done for today.
[15:38:04] <meffie> have a good evening
[15:38:11] <wiesand> Thanks a lot everyone!
[15:44:52] wiesand leaves the room
[15:45:56] meffie leaves the room
[16:15:36] Daria joins the room
[22:04:40] kadukoafs@gmail.com/barnowl93AC7D46 leaves the room
[22:04:49] kadukoafs@gmail.com/barnowl93AC7D46 joins the room