[CentOS-devel] Storage SIG Meeting minutes (OpenAFS only)

Here are my notes from the Storage SIG Meeting from 01 Oct 2014, just
for the OpenAFS parts. There were some communication difficulties near
the end of the meeting, but what I gathered is that I/Jonathan/Ross
would handle the minutes for the OpenAFS section, and Lalatendu would
write up notes for the rest. Karanbir was distracted or absent for the
last few points, I believe.

There were a few sections where I had trouble hearing/understanding, so
it is entirely possible some of the information here is wrong. But this
is what I could remember and understand.

Attending:

Andrew Deason
Jonathan Billings
Karanbir Singh
Lalatendu Mohanty
Ross Smith

 - Current status: Ross has created an initial spec file for packaging
   the userspace portions of OpenAFS, based on the spec file from
   upstream OpenAFS 1.6.9.

 - Next step: We need to figure out what to do about the kernel modules.

 - Andrew asks about the system for triggering builds based on kernel
   uploads.  Karanbir says the old system (this is maybe the 'distro
   buildsystem'?) supported these triggers/hooks, but the new
   buildsystem with Koji does not (yet?). The old system is being phased
   out and SIGs should only submit packages via Koji, so this 'triggers'
   approach is not usable yet. Karanbir mentioned a possible workaround,
   which I think is just what was mentioned on the list (a hook in the
   distro buildsystem calls out to Koji).

 - Andrew raises the issue that such 'triggers' would only cause kmods
   to be built with new kernel versions; it does not cause new OpenAFS
   versions to be built against old kernels. Doing so requires building
   OpenAFS against all older kernel versions upon a new release of
   OpenAFS.  Karanbir explains that while the extra load caused by this
   is not a problem, you can't just build "foreach" kernel version, and
   in fact many of the older kernel releases get deleted, so they will
   not be available to build against.  One way of moving forward is to
   just not build kmods for kernels older than the current openafs
   release, but this will be a problem for sites that want to upgrade
   OpenAFS without upgrading their kernel.

 - Jonathan notes that if we restrict this to EL7 and newer, at least
   for now, the number of kernels is much smaller. Since in addition to
   just having fewer kernel revisions, there are fewer variants (x86,
   PAE, etc).

 - Karanbir suggests that for now, we just go with the easiest thing
   that at least minimally works (e.g. just akmods or DKMS). Working out
   how to handle plain kmods can be deferred and based on user feedback.

 - Jonathan raises the question of akmods vs DKMS; why do akmods seem
   more popular? Karanbir's answer involved something about the
   dependencies, but I did not catch (or have forgotten) the details.

 - Karanbir asks if he should start pushing the existing packaging into
   the buildsystem and into CentOS. Andrew suggests we should wait until
   at least something with the kernel modules is figured out, and a
   little more testing with the server components. Ross mentions he just
   tested the client portions, using an upstream kmod.

 - Andrew solicits opinions on the existence of the 'compat' and/or
   'transarc' packages (at least for now); no objections, and no strong
   opinions on whether these remain as two separate packages or as one.
   The names openafs-compat and openafs-transarc may not be clear for
   new users, but their meanings are clear for older users of OpenAFS
   (who are the only people that care about them).

 - Andrew asks about what the 'Packager' should be set to in the spec
   file.  Lalatendu I think mentioned we can just set it to the Storage
   SIG, and we don't need to specify an email address.

 - Andrew asks about obtaining access to try building packages through
   Koji. I think the response was that this is pretty open and easy to
   obtain (at least for sandbox testing), and I just need to go look at
   it. [I'm sure more specific information was given to me here, but I
   didn't hear it, sorry.]

So, based on that meeeting, here is what I think the next actions are:

 - Ross is to try a pass at packaging the kernel module via a separate
   spec file, without worrying about regular kmods; just dynamically
   building the modules on the client machine is fine for now.

 - Andrew is to test and try out the servers in the existing packages.

 - Andrew will create 'compat' and 'transarc' packages (I'll submit pull
   requests). (Or if Ross or anyone else wants to, go ahead, but I
   assume I am to do this if I don't hear anything else.)

-- 
Andrew Deason
adeason at sinenomine.net