[CentOS-devel] Balancing the needs around the RHEL platform

On Wed, Dec 30, 2020 at 5:55 AM Ljubomir Ljubojevic <centos at plnet.rs> wrote:
>
> On 12/30/20 9:47 AM, Nico Kadel-Garcia wrote:
> > On Tue, Dec 29, 2020 at 7:04 AM Phil Perry <pperry at elrepo.org> wrote:
> >>
> >> On 28/12/2020 23:32, Lamar Owen wrote:
> >>>
> >>>
> >>> Will Stream cut it for me?  One issue that keeps getting glossed over is
> >>> that many drivers that are already in-kernel, not 3rd party, but
> >>> disabled by Red Hat, still have users who need them.  ELrepo and others
> >>> have provided support at the "point release" milestones for these
> >>> "unsupported" drivers; it really looks like Stream will break this hard.
> >>>
> >>> For instance, I need megaraid_sas for my servers; that's not a 3rd party
> >>> binary driver, but is already in-kernel; it is intentionally not built
> >>> by Red Hat.  ELrepo rebuilds this AND most importantly provides a
> >>> working driver disk for installs; I just don't see Red Hat providing
> >>> these drivers, even in a SIG, for hardware they have already decided is
> >>> "unsupported "; but I always reserve the right to be wrong.
> >>>
> >>
> >> Hi Lamar,
> >>
> >> Unfortunately there's an issue with driver disk ISO images too, as they
> >> are based on point release GA kernels (as are most all OEM ISO driver
> >> disks), and Stream regularly releases new installation media based on
> >> the latest Stream kernel, so if you need a 3rd party driver disk to
> >> install, you are probably out of luck and may not even be able to
> >> install CentOS Stream, even if a driver were available. I'm guessing for
> >> the next year you could install CentOS Linux 8 and convert to Stream,
> >> but after 2021 that will no longer be an option.
> >
> > He should also consider finding a more reputable hardware vendor.
> > Those so-called "megaraid" chipsets were abominable monstrosities and
> > there were a number of extremely poorly written vendor kernel hacks
> > supporting them.
> >
> > Why wouldn't installing from CentOS 8.3 and updating to CentOS Stream
> > be an option? The yum repos are well defined, in well-defined RPMs.
> > And an add-on internal RPM to point to a locked internal repository to
> > provide a "base OS imae" snapshot is a commonplace practice for EPEL,
> > one I've used effectively myself to lock the "update" channels from
> > RHEL and CentOS for consistency in cluster deployment. The approach
> > costs time and effort to set up, and some internal resources, but it
> > provides much faster "yum update" or "yum check-update" operations
> > than always reaching out to the central repos. It's also very useful
> > when you need to rebuild or update 200 cluster members simultaneously,
> > and the yum metadata alone will overwhelm your external bandwidth.
> > _______________________________________________
>
> And dozens or hundreds of thousands of regular users with need for 3rd
> party drivers and no time and/or money for carefully maintained internal
> repositories?

Anyone who has to this kind of 3rd party integration is already
devoting time and resources to it. The space for a snapshotted
internal mirror is quite modest, the cooperation with internal
architects is the expensive resource And keeping people from investing
a much larger engineering and cash investment in a "spacewalk" system
which will spend many man-hours on hand-tuning individually tuned RPM
lists for individual servers is.... well, it's one of those
discussions that makes DevOps DevOps. that is ordinarily a *much*
bigger expense. The primary difficulty is when Red Hat sells RHN as
part of a "pure Red Hat solution" and it won't properly handle CentOS
or EPEL or other third party channels. RHN in this setup would need to
cache and enable RPM's that have been deleted from the upstream
repositories, such as CentOS Stream and EPEL, and *that* argument
requires very, very careful attention. It's vastly cheaper to just set
up your own locked internal repo and stay away from the RHN tuning
arguments.

The time spent  for a maintained internal repository is really quite
modest: the github repo I publish for useful tools for one dates back
to 2014, with reposync-rhel8.sh tools from 2019 if you feel the need
for those. It's often well worth the benefit in update performance and
deployment to use an internal mirror. Snapshotting those takes some
thought, but is possible with the old "rsnapshot" tool, which I also
did some work with when it was published back in.... 2003.

In other words, these are not new problems. They have some available
workarounds. I publish places to start if you'd care to try them out.

Nico Kadel-Garcia