[CentOS-devel] First round of RHEL programs announced

Mike McGrath

mmcgrath at redhat.com
Thu Jan 28 21:38:55 UTC 2021


On Thu, Jan 28, 2021 at 3:16 PM Neal Gompa <ngompa13 at gmail.com> wrote:

> On Thu, Jan 28, 2021 at 3:55 PM Gena Makhomed <gmm at csdoc.com> wrote:
> >
> > On 28.01.2021 14:54, Neal Gompa wrote:
> >
> > > On Thu, Jan 28, 2021 at 6:22 AM Gena Makhomed <gmm at csdoc.com> wrote:
> >
> > >> What is about running in the one bare metal RHEL server virtual
> machines
> > >> with different subscription owners? For example, run in production on
> > >> one bare metal server 16 VMs with subscription owner Alice, and 16 VMs
> > >> with subscription owner Bob, and 16 VMs with subscription owner Carl,
> > >> and so on. Are such configurations legal and allowed or not? I didn't
> > >> find any limitations on the blog article, but for sure and for future
> I
> > >> need a clean and unambiguous answer from Red Hat.
> > >>
> > >> If such configurations are allowed - this is a legal workaround for a
> > >> limit of 16 no-cont RHEL instances. For example, a small company, with
> > >> 50 employees can absolutely legally have free and no-cost 800 RHEL
> > >> servers in self-support mode. Company with 100 employees can have 1600
> > >> free no-cost RHEL servers in self-support mode and so on.
> > >>
> > >> If such configurations are forbidden (on what basis?) - I have no
> choice
> > >> but to migrate from free CentOS and no-cost RHEL to Oracle Linux or
> Alma
> > >> Linux or Rocky Linux.
> > >>
> > >> And in the future if my company grows and I will need to buy
> commercial
> > >> support - I will be forced by Red Hat's decision to buy subscriptions
> > >> for Oracle Linux from the Oracle Corporation?
> > >>
> > >> Is this the real goal of the no-cost RHEL 16 instance limit - force
> > >> CentOS users migrate to Oracle Linux?
> >
> > > Brian Exelbierd explained this whole thing quite well on the Ask Noah
> > > Show[1]. The answer to this is that what you're saying is perfectly
> > > allowed. The bet here is that this is sufficiently costly, risky, and
> > > a hassle (who wants to manage 100+ Red Hat accounts? I know I
> wouldn't!)
> > > that the company in question would decide to purchase RHEL
> > > subscriptions from Red Hat, especially after experiencing the value
> > > that Red Hat provides (Red Hat Insights, live kernel patching, etc.).
> >
> > But did you know the minimal price of one RHEL Server subscription?
> >
> > ~ 350 USD/year.
> >
> > So, subscription for 100 servers/VMs will be cost 35_000 USD/year.
> >
> > Every year. For 10 years price of 100 subscriptions is 350_000 USD.
> >
> > You don't need 100 Red Hat accounts, for 100 server subscriptions.
> >
> > For 112 RHEL Server subscriptions you need only 7 Red Hat accounts.
> >
> > 16 * 7 == 112.
> >
> > Managing 7 Red Hat accounts really is sufficiently costly, risky,
> > and a hassle? I don't see any problems with such work for 7 accounts.
> >
> > For 1600 servers minimal commercial price is 560_000 USD/year.
> > and price is 5_600_000 USD for 10 year subscription. For 1600 servers.
> >
> > Managing 100 Red Hat accounts really is sufficiently costly, risky,
> > and a hassle? This work cost more then 5_600_000 USD for 10 years?
> >
>
> It can be quite a hassle, especially if they have to be keyed to
> individual accounts and automation and such can only provision from
> one set of credentials at a time. At larger scale setups, it becomes
> quite messy and involved to actually maintain that.
>
>
I also believe those individual accounts are tied to the individual.  If
they leave a company - their subscriptions go with them.

           -Mike


> From experience, I can already say it's a pain to manage *one* Red Hat
> account, much less 7 or 100. It's not just the money, it's the labor
> and the opportunity costs.
>
> > I don’t understand one thing, if it is so easy to get workaround
> > these restrictions of 16 no-cost RHEL instances and at the same time
> > bypassing these restrictions is completely legal - why were these
> > restrictions introduced at all?
> >
> > So that CentOS users should think about whether they should
> > switch to no-cost RHEL, or maybe they should think about switching
> > to completely free variant of Enterprise Linux from Oracle, which
> > does not have such restrictions on the number of no-cost instances
> > and don't need any subscriptions for seamless work at all?
> >
> > As previously CentOS Linux users live (mostly) without commercial
> > subscription and support from RHEL, the same in the future,
> > they can live with no-cost Oracle Linux (mostly) without
> > commercial subscription.
> >
> > If user of mass installation of Oracle Linux in future need commercial
> > support - he/she will buy commercial support from Oracle Corporation,
> > not from Red Hat/IBM. It's obvious, isn't it? Money will go to Oracle.
> >
> > This is some kind of strange situation when the Enterprise Linux
> > was created by Red Hat staff and Fedora community, but the Oracle
> > Corporation will make additional money on it, because this is where
> > a large number of CentOS users can/will go in current situation.
> >
> > > What I would have liked to see is the addition of some generic
> > > low-cost subscription options that would be sufficiently below the
> > > floor to fit with even low-margin businesses so that as a business
> > > grows from 16, to 50, to 100, to 1000, and so on, the company would
> > > continue to use RHEL and continue to support the awesome work Red Hat
> > > does. Right now, the current pricing is so unbelievably expensive that
> > > I would instead just convert the boxes from RHEL to CentOS Stream
> > > after a certain threshold.
> >
> > CentOS Stream is just a beta-version for next minor RHEL release.
> >
> > CentOS Stream is not ready for production, see for example,
> > bugreport https://bugzilla.redhat.com/show_bug.cgi?id=1913806
> > - this bug is present in CentOS Stream 8, but absent in CentOS 8.3.
> >
>
> Meh. Legacy CentOS Linux gets serious bugs all the time too. I had
> dozens of AMD servers that wouldn't boot because of a critical bug
> introduced in CentOS 7.3. There was a whole cycle where I had to hold
> back kernels because they couldn't release a fix until CentOS 7.4
> arrived.
>
> At least with CentOS Stream, when the fix is made, I'll get it right
> away. That's better than before.
>
> > > I firmly believe that low-cost self-support options would be a good
> > > value for Red Hat to offer to the market, especially for a lot of
> > > those startups that eventually grow past the 16 server limit. I hope
> > > that's on the docket based on the comment at the top of the RHEL blog
> > > post that this is the first of many new programs.
> >
> > I hope so too, because if they do nothing, then many CentOS users will
> > simply leave for Oracle Linux. I just don't see any other way out now.
> >
>
> I'm optimistic. I know the folks at Red Hat are doing their best, and
> I have faith in them.
>
>
>
>
> --
> 真実はいつも一つ!/ Always, there's only one truth!
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20210128/6fafc4b7/attachment.html>


More information about the CentOS-devel mailing list