While not to the same level of automation and install numbers, we run it on
50-100 serves updating monthly and can report a similar experience and
level of satisfaction.
We've had one major issue when Intel fixed it's HMM to behave as advertised
but again, a quick google and we were good within acceptable timeframes.
We do have special equipment - the Cisco M Series servers - and the kernel
v 3 doesn't have drivers for the LUNs in those - so we used initially out
of necessity. But now, as Sam notes, we use because it's more stable and
On Wed., 11 Jul. 2018, 19:30 Sam McLeod, <mailingli...@smcleod.net> wrote:
> As Phil says, the kernels are provided 'as-is', but I'd like to give you a
> quick sample of how we've found it in production.
> We run anywhere between 250-2000 CentOS 7 VMs each year.
> We have been using elrepo kernel-ml on both our VMs and our physical SANs
> / storage servers and our physical backup servers for the past 3~ years.
> We install the latest kernel-ml package as soon as it's available (we
> automate everything, the kernel package is ensured that it is the latest
> available every 20 minutes~).
> In those 3~ years we have had (from memory) two problems:
> 1. Only affected our storage servers, it was some odd kernel bug that
> caused some DRBD issues, when we noticed a pattern we just booted into the
> previous kernel and the bug was fixed (upstream, in the kernel itself)
> about 5 releases later (it wasn't very well reported to the kernel devel
> team or it would have been quicker, at any rate - nothing to do with elrepo
> or kernel-ml).
> 2. A problem that may have affected intel 7xx series NICs that was again
> an upstream kernel bug, saw the problem straight after rebooting into the
> new kernel, rebooted into the last kernel - it was fine, left it for a
> couple of days until the next build was out - tried it and it was fine.
> Other than that - kernel-ml has do nothing but provide us with *much* better
> performance and new features (we use a lot of 'newish' things like NVMe,
> containers before they were cool, new hardware, self design software
> defined storage / SANs etc....).
> For me and my engineering team it's an absolute no-brainer to use
> kernel-ml and there's no way we'd be seen dead running the stock centos 3.x
> kernels to be honest.
> note: we don't use any weird 'black box' oracle / ibm or the likes
> hardware that require special kernel drivers to be installed etc... but I
> haven't seen people do that much on x86 these days anyway.
> Sam McLeod
> On 11 Jul 2018, at 08:39, Phil Perry <p...@elrepo.org> wrote:
> On 10/07/18 18:57, Pedro Flores wrote:
> We recently started using ELRepo’s kernel repositories in a subset of our
> production infrastructure to deal with some issues we were experiencing
> with CentOS 7.5 latest kernels. Our security team has some concerns about
> how quickly ElRepo releases new kernel packages that address either major
> bug fixes or CVE exploits after the kernels containing these updates have
> been released by the Linux Kernel Main archives. Is there a certain
> amount of time that we should expect new kernels to make it to ELREpo yum
> repositories after they have been released by the Linux Kernel Archives
> Thanks in advance.
> *Pedro Flores*
> Hi Pedro,
> Did you read the release announcement(s)? The relevant part to your
> question is here:
> These packages are provided "As-Is" with no implied warranty or
> support. Using the kernel-lt/-ml may expose your system to security,
> performance and/or data corruption issues. Since timely updates may
> not be available from the ELRepo Project, the end user has the
> ultimate responsibility for deciding whether to continue using the
> kernel-ml packages in regular service.
> Your security team are free to review our previous performance to get an
> indication for how quickly kernel packages are typically released, but past
> performance should not be taken as a guarantee for future release time
> If you have issues with the EL7.5 kernel in a production environment and
> do not have the expertise to fix it in house, I would highly recommend you
> purchase RHEL subscriptions and raise a support case directly with Red Hat
> to have your issues resolved. As stated in our release announcement(s), our
> kernel packages are not intended for production use. Elrepo is a voluntary
> project and Alan handles all kernel builds single-handedly on donated
> limited build hardware. As such, we are unable to offer you any guaranteed
> level of service, hence my recommendation to purchase RHEL subscriptions if
> that is what you require.
> Hope that helps,
> elrepo mailing list
> elrepo mailing list
elrepo mailing list