Red Hat cutting back RHEL source availability
Red Hat cutting back RHEL source availability
Posted Jun 21, 2023 19:02 UTC (Wed) by jccleaver (guest, #127418)In reply to: Red Hat cutting back RHEL source availability by Vipketsh
Parent article: Red Hat cutting back RHEL source availability
After the financial issues with donations that CentOS had, and then once RH took over the project, RH actively pushed away people who wanted to write checks to ensure the larger EL ecosystem remained viable. The root of this is that RH's licensing fees make no sense for companies that don't need every box to be certified AND have their own (often large) staffs of Sr. Linux Engineers on duty. All of this was made very clear when CentOS Linux was pulled away in favor of Stream only.
Something like $350/box/yr for 1000s of boxes just doesn't make sense. We need RH for escalation points, but it's not like the 1000s of boxes are doing unique workloads or require individualized support. I worked for a large company that had maybe 3 different workloads across 8 different models of Dell hardware running at any given moment, across a huge farm. That's 3x8 combos of things that could go wrong where we need to phone RH for support, and everything else we'd handle ourselves.
We're not paying $350/box/yr for that if we don't need a certified OS on each system, but we'd pay a hefty site license fee and throw in a non-profit donation to the CentOS Foundation if we could have (and if it meant we got 4h SLAs on tickets). RH sells proprietary bits, but it doesn't sell a proprietary *platform* and the RH execs seem unable to comprehend this.
Posted Jun 22, 2023 10:12 UTC (Thu)
by paulj (subscriber, #341)
[Link] (5 responses)
"It doesn't matter how many boxes I run" is only true for (near) 100% hit-rate bugs.
Posted Jun 22, 2023 11:21 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (2 responses)
There's room for a compromise solution from RH, though. At 100,000 systems, you need a team who can correlate errors and distinguish hardware errors from software errors, whereas with 3 boxes, I can't make that distinction easily.
Thus, while the company with 100,000 systems will see a problem that occurs once in every 1,000,000 minutes every day, and raise a ticket, whereas I'll only see it every year or so, the ticket from the company with 100,000 systems is likely to be much easier to debug than mine, since my ticket is "this is a bug - it's occurred once, and then not again after a reboot, but I'm confident from the logs that it's a software fault. I'm not sure how to reproduce or test a fix", where the 100,000 system company will be raising a ticket of the form "this is a bug - you can see in these 100 logs that it's consistent. We can reproduce daily, and thus can test fixes in about a week".
Posted Jun 22, 2023 17:18 UTC (Thu)
by hkario (subscriber, #94864)
[Link] (1 responses)
Posted Jun 22, 2023 19:56 UTC (Thu)
by zdzichu (subscriber, #17118)
[Link]
Posted Jun 22, 2023 19:00 UTC (Thu)
by jccleaver (guest, #127418)
[Link] (1 responses)
Ehh, I'd say it's true for anything you can derive a reproducer for. But in my experience at $job-=3, that often *was* the case.
Most of our problems came about under high load conditions, sometimes with specific hardware thanks to a driver bug or whatnot, or with our app or DB doing something weird after a specific kernel update but working fine before. But the first line of defense for a large environment is always going to be your own SysEng/SysAdmin team, not RedHat Support. We'd be doing the isolation work to narrow down the problem as specifically as we can before we Phone a Friend and escalate because ultimately it's our job internally to keep those systems running.
I have no idea if RHEL subscribers as a whole treat RH as frontline Linux tech support, but that certainly wasn't our need and we weren't going to pay out the ass for that purely based on cores where the underlying product is still OSS. I can't believe the CentOS folks didn't realize that, but based on the behavior of others at RedHat, I very much believe that some of the other folks there didn't.
Posted Jun 22, 2023 22:42 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
The only place I've worked that bought RHEL expected Red Hat Support to answer questions like "why does 'ln -sr' not remove the destination file if it already exists?" and "why does 'scp root@11.5.0.1:/file file' fail with a Connection timed out error when ssh root@10.5.0.1 works?"
I have no idea how prevalent that sort of behaviour was (and that place had under 10 servers running RHEL, so not a big burden for RH - it was mostly a Windows shop), but it's something RH have to account for.
I'd also note that because RH engineers participate upstream, including in CentOS Stream, if you're reporting your issues upstream once you find them, RH engineers may well get involved with the fix, to forestall their customers making the same demand later. This has happened to me with Xorg bugs in the past, where RH engineers fixed the bug upstream, precisely because they understood my bug report, and were able to fix it.
All you'd be paying RH for is the ability to get RH engineers to prioritise your bug over all the other things they do; a support contract where instead of charging per-server, they charge based on the number of incidents you can raise might well work for your situation - you pay to get access to the RH Knowledge Base, and to raise (say) 10 incidents per year with RH support, rather than paying for 10 servers.
Red Hat cutting back RHEL source availability
Red Hat cutting back RHEL source availability
Red Hat cutting back RHEL source availability
Red Hat cutting back RHEL source availability
Red Hat cutting back RHEL source availability
Red Hat cutting back RHEL source availability