Thanks everyone for your responses.   I do feel better now about relying on 
ELRepo's kernels for our particular use case based on your experiences.

--


On 7/11/18, 7:47 AM, "elrepo-boun...@lists.elrepo.org on behalf of Robin P. 
Blanchard" <elrepo-boun...@lists.elrepo.org on behalf of 
robin.blanch...@gmail.com> wrote:

    We run kernel-ml in production on physical (HP MoonShot, Cisco UCS M)
    and virtual machines. Our primary push was for all the updated CIFS
    support in kernels > 4.11.
    On Wed, Jul 11, 2018 at 5:13 AM Lachlan Musicman <data...@gmail.com> wrote:
    >
    > 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 
secure.
    >
    > Cheers
    > L.
    >
    >
    > On Wed., 11 Jul. 2018, 19:30 Sam McLeod, <mailingli...@smcleod.net> wrote:
    >>
    >> Pedro,
    >>
    >> 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
    >> 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsmcleod.net&amp;data=02%7C01%7Cpedro.flores%40q2ebanking.com%7C9fb60206e539428a1b2e08d5e72c8223%7C86b383240fb644c7b3dc5dc60d472331%7C0%7C1%7C636669100715904706&amp;sdata=MIMNTuRoY1mzAWzXismUqGnXQiMTjvNWO5po39j%2FXLo%3D&amp;reserved=0
    >> 
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2Fs_mcleod&amp;data=02%7C01%7Cpedro.flores%40q2ebanking.com%7C9fb60206e539428a1b2e08d5e72c8223%7C86b383240fb644c7b3dc5dc60d472331%7C0%7C0%7C636669100715904706&amp;sdata=x9p6yG9KRfoxKYbu3YgQCQvqhA3EzgZ45b1ryc%2B27Eo%3D&amp;reserved=0
    >>
    >> 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 folks?
    >> 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 scales.
    >>
    >> 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,
    >>
    >> Phil
    >>
    >> _______________________________________________
    >> elrepo mailing list
    >> elrepo@lists.elrepo.org
    >> 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.elrepo.org%2Fmailman%2Flistinfo%2Felrepo&amp;data=02%7C01%7Cpedro.flores%40q2ebanking.com%7C9fb60206e539428a1b2e08d5e72c8223%7C86b383240fb644c7b3dc5dc60d472331%7C0%7C1%7C636669100715904706&amp;sdata=X4NsMlvIhD%2BpK6CToFPB8AJq3N7K1rjcvjeyMDM2e8w%3D&amp;reserved=0
    >>
    >>
    >> _______________________________________________
    >> elrepo mailing list
    >> elrepo@lists.elrepo.org
    >> 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.elrepo.org%2Fmailman%2Flistinfo%2Felrepo&amp;data=02%7C01%7Cpedro.flores%40q2ebanking.com%7C9fb60206e539428a1b2e08d5e72c8223%7C86b383240fb644c7b3dc5dc60d472331%7C0%7C1%7C636669100715914715&amp;sdata=6kMBy74kN4kV4SXJg5MqqcAIA4mxSe0vfRSlgklTLo8%3D&amp;reserved=0
    >
    > _______________________________________________
    > elrepo mailing list
    > elrepo@lists.elrepo.org
    > 
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.elrepo.org%2Fmailman%2Flistinfo%2Felrepo&amp;data=02%7C01%7Cpedro.flores%40q2ebanking.com%7C9fb60206e539428a1b2e08d5e72c8223%7C86b383240fb644c7b3dc5dc60d472331%7C0%7C1%7C636669100715914715&amp;sdata=6kMBy74kN4kV4SXJg5MqqcAIA4mxSe0vfRSlgklTLo8%3D&amp;reserved=0
    _______________________________________________
    elrepo mailing list
    elrepo@lists.elrepo.org
    
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.elrepo.org%2Fmailman%2Flistinfo%2Felrepo&amp;data=02%7C01%7Cpedro.flores%40q2ebanking.com%7C9fb60206e539428a1b2e08d5e72c8223%7C86b383240fb644c7b3dc5dc60d472331%7C0%7C1%7C636669100715914715&amp;sdata=6kMBy74kN4kV4SXJg5MqqcAIA4mxSe0vfRSlgklTLo8%3D&amp;reserved=0



[https://www.q2ebanking.com/docs/EmailSignature_TX.png]

[https://www.q2ebanking.com/docs/EmailDisclaimer.png]
_______________________________________________
elrepo mailing list
elrepo@lists.elrepo.org
http://lists.elrepo.org/mailman/listinfo/elrepo

Reply via email to