Re: CentOS and Debian/Ubuntu release cycles
On 12/10/20 9:06 PM, Joel Wirāmu Pauling wrote:
>
>
> On Fri, Dec 11, 2020 at 8:51 AM Geert Stappers <stappers@stappers.nl
> <mailto:stappers@stappers.nl>> wrote:
>
> On Thu, Dec 10, 2020 at 05:16:28PM +0100, Marco d'Itri wrote:
> > On Dec 10, Paul Wise <pabs@debian.org <mailto:pabs@debian.org>> wrote:
> > > Both of these situations sound like things that should get solved by
> > > rewriting the vendor/O-O-T code and including it in mainline
> > > Linux/etc, is there any chance of that happening? Or alternatively,
> > The Fibre Channel drivers ARE all upstreamed, it's just that the
> inbox
> > drivers (i.e. distributed with the OS, in vendors speak) are not
> > qualified to receive support (and may be buggy, even in RHEL).
> > Storage vendors provide a support matrix with supported releases
> of the
> > storage firmware, FC switches firmware, network adapter firmware,
> OS and
> > OS driver. Anything else may not receive support.
> >
> > > for significant future hardware acquisitions, require mainline
> support
> > > before purchase.
> > Obviously, but I am not aware of any such FC/FCoE hardware (not
> just the
> > network adapters, but also the storages).
>
> Acknowledge on that problem.
> Do know that it can and must be solved by wallet.
> So do talk with your purchase department.
>
>
> Being out of Kernel means it is out of support or an approved support
> exception, one of the benefits of paid RHEL is hardware vendors both
> reach out to us, and we reach out to them to ensure certification and
> capability. Generally prior to something going to market.
>
> I hear your pain tho, I have a heap of Dell servers with deprecated HBA
> controllers in RH8 that I need to schlep in elrepo modules for drives to
> show up. That decision however was made because no-one in mainline is
> able to solve vendor issues and the vendor has disappeared (related to a
> PowerPC chip design flaws in a heap of Sandybridge era Raid
> controllers). We went down the big red warnings route in RH7 and people
> ignored them and had data lost and then blamed RH. Which is untenable ;
> a lot of hardware specific support falls into this category; and 100%
> this is something careful selection solves and is part of your Risk
> assessment as an Org. It also puts a LTS CentOS at odds of being able to
> track our source trees, one of the problems this is attempting to
> ameloirate.
>
> So in all those situations given here, yes, CentOS drivers that exist
> only in CentOS land really put the entire premise of a Stable Long Lived
> and robust OS at odds with the reality yes, absolutely.
>
> The ability to compile modules against the RHEL sources is not going
> away. So you can still run your junk with RHEL (out of support). The
> streams kernel also likely will solve this issue.
Gosh... reading that, I'm really happy I'm not (and never was) a CentOS
user. Seriously, this looks terrible!
Cheers,
Thomas Goirand (zigo)
Reply to: