[CentOS-devel] openafs status?

[Jason Edgecombe]

On 08/18/2015 01:28 PM, Ned Slider wrote:
>
> On 18/08/15 01:09, Jason Edgecombe wrote:
>> On 08/15/2015 07:52 PM, Ned Slider wrote:
>>> On 15/08/15 22:41, Jason Edgecombe wrote:
>>>> On 08/15/2015 10:56 AM, Ned Slider wrote:
>>>>> On 15/08/15 14:27, Jonathan Billings wrote:
>>>>>> On Aug 15, 2015, at 9:10 AM, Jason Edgecombe
>>>>>> <jason at rampaginggeek.com>  wrote:
>>>>>>> What's the plan for fixing CBS to accommodate this? If I had a spare
>>>>>>> afternoon, what could I do to move this forward?
>>>>>> Really, the end goal is to have the kmod-openafs packages built for
>>>>>> every kernel release as it comes out, without removing the existing
>>>>>> kmod-openafs from the repo.  This is why I separated it out from the
>>>>>> openafs spec/srpm, because it will need to be rebuilt every time
>>>>>> there is a new kernel.  However, OpenAFS users want to have
>>>>>> historical kmods available.
>>>>>>
>>>>> Given that you really don't seemed to have moved forward in the last
>>>>> year, I would reiterate what I said a year ago:
>>>>>
>>>>> http://lists.centos.org/pipermail/centos-devel/2014-September/012047.html
>>>>>
>>>>>
>>>>> I really don't understand why you would not want to use the framework
>>>>> Red Hat provides to solve exactly this problem. You are trying to solve
>>>>> a problem that is largely already solved.
>>>>>
>>>>> Worst case scenario is you'd need to rebuild kmod-openafs for major
>>>>> point releases every 9-12 months (e.g, 6.5, 6.6, 6.7; and/or 7.0, 7.1,
>>>>> ...) where the kABI is broken for non-whitelisted symbols used by
>>>>> OpenAFS. That has to be a preferable solution for OpenAFS users than
>>>>> rebuilding against each and every kernel release.
>>>>>
>>>> Does yum check and prevent or warn you when installing a kABI module for
>>>> a non-matching kernel? How do I know which kmods match my kernel?
>>>>
>>> No, yum will only warn on symbols that may be missing, for example on
>>> older kernels.
>>>
>>> Look to see if the module weak links against the kernel in the
>>> corresponding weak-updates directory.
>>>
>>> Sometime a module can weak link but still not be compatible but it's
>>> uncommon and only likely to happen when going from one point release to
>>> another (e.g, 6.6 to 6.7) when Red Hat have changed the kABI of a
>>> non-whitelisted symbol used by your module. Pre-release testing will
>>> pick this up. Red Hat generally do not change the kABI within a point
>>> release.
>> A few folks in the OpenAFS community have been burned by the kABI and
>> don't trust it, even for point RH releases. One gentleman was even
>> burned by elrepo.
>>
> People tend to not trust what they don't understand. kABI does exactly
> what it says on the tin - nothing more, nothing less. IMHO "burned"
> seems a bit strong but lets look at that.
>
> People tend to get "burned" when their expectations do not aline with
> reality. In reality kABI tracking kmods work seamlessly when the driver
> uses only symbols on the whitelist (and in my experience that is
> actually very few to none).
>
> As I understand, OpenAFS uses some non-whitelisted symbols so the
> reality is that openafs may break at point releases. It should work
> seamlessly for kernel updates between point releases. In other (your)
> words, you *may* get burned at a point release.
>
> Compare that to compiling against every single kernel release. That
> guarantees the existing module(s) will break for every new kernel
> release, so now instead of getting "burned" every 9 months at a point
> release, users now get "burned" at every kernel update.
>
> Lets look at an example. Every couple weeks RH release a kernel update
> but I can't update because my matching kmod-openafs isn't available yet.
> First I have to wait for CentOS to rebuild it and release the kernel
> update (lag). Then I have to wait for the SIG to rebuild their
> kmod-openafs against the newly built CentOS kernel (more lag). If I
> accidentally update my kernel and reboot - poof, I'm burned. Every time,
> guaranteed. If I don't update my kernel then compliance are on my case
> because I'm vulnerable to the latest CVE.
>
> Personally, if I'm gonna get burned I'd rather be burned every 9 months
> that every single time upstream releases a new kernel update.
>
> Of course in the real world, where people are using filesystem drivers
> in production, I'm sure they test any new releases before they put them
> into production so they never actually get burned. What they do get is a
> heads up when there is an issue, they file a bug, the driver gets
> rebuilt, the issue is solved and the bug is closed. It's that simple.
>
> I don't use OpenAFS so I really don't care if you build against every
> kernel or use kABI tracking kmods. As I've said before, there is no
> precedent in RHEL to build kmods against each kernel - kABI tracking
> kmods is the RHEL way. Given that you don't seem to have progressed from
> a year ago and kABI tracking kmods do not suffer from the problem you
> have made for yourselves, it just seemed like the obvious solution. A
> few folks in the OpenAFS community having a bad experience doesn't seem
> like a valid reason for throwing out the established way of doing things
> and adopting something that has the potential to cause far more issues
> and has no precedence in the RHEL ecosystem. If you want to deviate from
> the established method then I really think you need to (1) present a
> stronger case why you believe it doesn't work, and (2) present a viable
> alternative that significantly improves on the currently established
> methods.
>
> TBH it all seems fairly irrelevant now as I would imagine any users
> waiting for a solution are long gone by now.
Is there a yum repo or easy way to download RPMs from CBS if I want to 
try them for myself?

I'm just an OpenAFS community member, not one of the main packagers. It 
seems that I'm hard-pressed to convince either side to switch.

Jason