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