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

On Thu, 31 Dec 2020 at 07:49, Nico Kadel-Garcia <nkadel at gmail.com> wrote:

> On Wed, Dec 30, 2020 at 12:42 PM Lamar Owen <lowen at pari.edu> wrote:
> >
> > On 12/30/20 3:47 AM, Nico Kadel-Garcia wrote:
> > > He should also consider finding a more reputable hardware vendor.
> >
> > Hey Nico, I'm right here.... :-)  Anyway, these servers are Dell.  Dell
> > isn't a reputable vendor these days?
>
> I've not looked this year. They need careful attention to avoid
> changing parts or chipsets without notification and breaking
> compatibility with your current, stable kernel. They all do. It was
> why, when I did hardware evals, I made sure to get one of any new
> model we wanted to order, put it in my test rack, and keep it there
> for kernel and OS deployment testing.
>
> > In any case, it's a moot point, since I didn't pick these servers, the
> > servers picked me (that is, they were donated to us, and, to modify an
> > old saying in my area of the world, "never look a gift server in the
> > RAID controller."  (the original expression: "never look a gift horse in
> > the mouth.")).
>
> If they cost you that much work, consider buying modest Adaptec RAID
> controllers. MegaRAID had a bad habit of doing a lot of the RAID work
>

Adaptec controllers haven't existed as 'distinct' hardware since before
2010. Since then they have been rebranded controllers some of which are
MegaRAID, LSI and other systems. For the years between 2010 and 2018, the
Megaraid or LSI was a better bet than Adaptec.


> in the kernel, not on the attached hardware, which was why the kernel
> modules were so critical. And the add-on drivers from the vendor were
> usually at least a year behind those in the current Red Hat kernel and
> were in fact a regression, as long as we stuck to a contemporary Red
> Hat release. RHEL or CentOS these days. I'm very surprised if you have
> hardware that actually needs that third-party driver, though it may
> take work to get the latest kernel into a bootable ISO or PXE image.
>
>
RHEL8 kernels no longer comes with the megaraid controller enabled thus you
need the CentOS kernel. The third party module is just the one in the
normal kernel compiled.


> I have war stories about those drivers.
>
> > > Those so-called "megaraid" chipsets were abominable monstrosities and
> > > there were a number of extremely poorly written vendor kernel hacks
> > > supporting them.
> >
> > As mostly an end-user these days, I really couldn't care less what kind
> > of hacks are required.  I just know that we as a public charity were
> > donated these servers to put to use; I intend to put them to use in the
> > spirit of the US Internal Revenu Code Section 501(c)(3).  They beat the
> > two-generations-older Dell PowerEdge 1950s that they are replacing,
> > which still use the same basic RAID chipset and have serious performance
> > bottlenecks as KVM hosts with modern KVM.
>
> Makes you wonder why someone gave them away?
>
>
I believe there was a US Tax benefit for companies if they traded out their
hardware after 4 but before 8 years and donated their old hardware to
charities. Since there was a lot of hardware being 'donated' most of the US
charities only want to take items they can get extended warranties and
parts from the manufacturer from.. so getting a donated Dell is better than
a donated Supermicro.


> Back to CentOS Stream. One of the CentOS kernel advantages was that
> Red Hat apparently did test suites across a wide variety of hardware
> before considering a kernel for release. I'm afraid CentOS Stream
> kernels won't have that regression testing done.
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>


-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20201231/89f8560d/attachment.html>