<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jan 28, 2021 at 3:16 PM Neal Gompa <<a href="mailto:ngompa13@gmail.com">ngompa13@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, Jan 28, 2021 at 3:55 PM Gena Makhomed <<a href="mailto:gmm@csdoc.com" target="_blank">gmm@csdoc.com</a>> wrote:<br>
><br>
> On 28.01.2021 14:54, Neal Gompa wrote:<br>
><br>
> > On Thu, Jan 28, 2021 at 6:22 AM Gena Makhomed <<a href="mailto:gmm@csdoc.com" target="_blank">gmm@csdoc.com</a>> wrote:<br>
><br>
> >> What is about running in the one bare metal RHEL server virtual machines<br>
> >> with different subscription owners? For example, run in production on<br>
> >> one bare metal server 16 VMs with subscription owner Alice, and 16 VMs<br>
> >> with subscription owner Bob, and 16 VMs with subscription owner Carl,<br>
> >> and so on. Are such configurations legal and allowed or not? I didn't<br>
> >> find any limitations on the blog article, but for sure and for future I<br>
> >> need a clean and unambiguous answer from Red Hat.<br>
> >><br>
> >> If such configurations are allowed - this is a legal workaround for a<br>
> >> limit of 16 no-cont RHEL instances. For example, a small company, with<br>
> >> 50 employees can absolutely legally have free and no-cost 800 RHEL<br>
> >> servers in self-support mode. Company with 100 employees can have 1600<br>
> >> free no-cost RHEL servers in self-support mode and so on.<br>
> >><br>
> >> If such configurations are forbidden (on what basis?) - I have no choice<br>
> >> but to migrate from free CentOS and no-cost RHEL to Oracle Linux or Alma<br>
> >> Linux or Rocky Linux.<br>
> >><br>
> >> And in the future if my company grows and I will need to buy commercial<br>
> >> support - I will be forced by Red Hat's decision to buy subscriptions<br>
> >> for Oracle Linux from the Oracle Corporation?<br>
> >><br>
> >> Is this the real goal of the no-cost RHEL 16 instance limit - force<br>
> >> CentOS users migrate to Oracle Linux?<br>
><br>
> > Brian Exelbierd explained this whole thing quite well on the Ask Noah<br>
> > Show[1]. The answer to this is that what you're saying is perfectly<br>
> > allowed. The bet here is that this is sufficiently costly, risky, and<br>
> > a hassle (who wants to manage 100+ Red Hat accounts? I know I wouldn't!)<br>
> > that the company in question would decide to purchase RHEL<br>
> > subscriptions from Red Hat, especially after experiencing the value<br>
> > that Red Hat provides (Red Hat Insights, live kernel patching, etc.).<br>
><br>
> But did you know the minimal price of one RHEL Server subscription?<br>
><br>
> ~ 350 USD/year.<br>
><br>
> So, subscription for 100 servers/VMs will be cost 35_000 USD/year.<br>
><br>
> Every year. For 10 years price of 100 subscriptions is 350_000 USD.<br>
><br>
> You don't need 100 Red Hat accounts, for 100 server subscriptions.<br>
><br>
> For 112 RHEL Server subscriptions you need only 7 Red Hat accounts.<br>
><br>
> 16 * 7 == 112.<br>
><br>
> Managing 7 Red Hat accounts really is sufficiently costly, risky,<br>
> and a hassle? I don't see any problems with such work for 7 accounts.<br>
><br>
> For 1600 servers minimal commercial price is 560_000 USD/year.<br>
> and price is 5_600_000 USD for 10 year subscription. For 1600 servers.<br>
><br>
> Managing 100 Red Hat accounts really is sufficiently costly, risky,<br>
> and a hassle? This work cost more then 5_600_000 USD for 10 years?<br>
><br>
<br>
It can be quite a hassle, especially if they have to be keyed to<br>
individual accounts and automation and such can only provision from<br>
one set of credentials at a time. At larger scale setups, it becomes<br>
quite messy and involved to actually maintain that.<br>
<br></blockquote><div><br></div><div>I also believe those individual accounts are tied to the individual.  If they leave a company - their subscriptions go with them.</div><div><br></div><div>           -Mike</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
>From experience, I can already say it's a pain to manage *one* Red Hat<br>
account, much less 7 or 100. It's not just the money, it's the labor<br>
and the opportunity costs.<br>
<br>
> I don’t understand one thing, if it is so easy to get workaround<br>
> these restrictions of 16 no-cost RHEL instances and at the same time<br>
> bypassing these restrictions is completely legal - why were these<br>
> restrictions introduced at all?<br>
><br>
> So that CentOS users should think about whether they should<br>
> switch to no-cost RHEL, or maybe they should think about switching<br>
> to completely free variant of Enterprise Linux from Oracle, which<br>
> does not have such restrictions on the number of no-cost instances<br>
> and don't need any subscriptions for seamless work at all?<br>
><br>
> As previously CentOS Linux users live (mostly) without commercial<br>
> subscription and support from RHEL, the same in the future,<br>
> they can live with no-cost Oracle Linux (mostly) without<br>
> commercial subscription.<br>
><br>
> If user of mass installation of Oracle Linux in future need commercial<br>
> support - he/she will buy commercial support from Oracle Corporation,<br>
> not from Red Hat/IBM. It's obvious, isn't it? Money will go to Oracle.<br>
><br>
> This is some kind of strange situation when the Enterprise Linux<br>
> was created by Red Hat staff and Fedora community, but the Oracle<br>
> Corporation will make additional money on it, because this is where<br>
> a large number of CentOS users can/will go in current situation.<br>
><br>
> > What I would have liked to see is the addition of some generic<br>
> > low-cost subscription options that would be sufficiently below the<br>
> > floor to fit with even low-margin businesses so that as a business<br>
> > grows from 16, to 50, to 100, to 1000, and so on, the company would<br>
> > continue to use RHEL and continue to support the awesome work Red Hat<br>
> > does. Right now, the current pricing is so unbelievably expensive that<br>
> > I would instead just convert the boxes from RHEL to CentOS Stream<br>
> > after a certain threshold.<br>
><br>
> CentOS Stream is just a beta-version for next minor RHEL release.<br>
><br>
> CentOS Stream is not ready for production, see for example,<br>
> bugreport <a href="https://bugzilla.redhat.com/show_bug.cgi?id=1913806" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/show_bug.cgi?id=1913806</a><br>
> - this bug is present in CentOS Stream 8, but absent in CentOS 8.3.<br>
><br>
<br>
Meh. Legacy CentOS Linux gets serious bugs all the time too. I had<br>
dozens of AMD servers that wouldn't boot because of a critical bug<br>
introduced in CentOS 7.3. There was a whole cycle where I had to hold<br>
back kernels because they couldn't release a fix until CentOS 7.4<br>
arrived.<br>
<br>
At least with CentOS Stream, when the fix is made, I'll get it right<br>
away. That's better than before.<br>
<br>
> > I firmly believe that low-cost self-support options would be a good<br>
> > value for Red Hat to offer to the market, especially for a lot of<br>
> > those startups that eventually grow past the 16 server limit. I hope<br>
> > that's on the docket based on the comment at the top of the RHEL blog<br>
> > post that this is the first of many new programs.<br>
><br>
> I hope so too, because if they do nothing, then many CentOS users will<br>
> simply leave for Oracle Linux. I just don't see any other way out now.<br>
><br>
<br>
I'm optimistic. I know the folks at Red Hat are doing their best, and<br>
I have faith in them.<br>
<br>
<br>
<br>
<br>
--<br>
真実はいつも一つ！/ Always, there's only one truth!<br>
_______________________________________________<br>
CentOS-devel mailing list<br>
<a href="mailto:CentOS-devel@centos.org" target="_blank">CentOS-devel@centos.org</a><br>
<a href="https://lists.centos.org/mailman/listinfo/centos-devel" rel="noreferrer" target="_blank">https://lists.centos.org/mailman/listinfo/centos-devel</a><br>
</blockquote></div></div>