On Thu, Jan 28, 2021 at 6:22 AM Gena Makhomed <gmm at csdoc.com> wrote: > > On 20.01.2021 15:14, Mike McGrath wrote: > > > Hi all, I know this was a hot topic on the list so I thought I'd share > > today's blog post which covers no-cost RHEL for small production workloads > > and no-cost RHEL for customer development teams. Keep in mind there are > > other programs coming, these just got done first. > > > > https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-programs-easier-ways-access-rhel > > > > Bullet Points: > > > > - Self-Support RHEL for no-cost in production use cases of up to 16 > > systems. > > - No-cost RHEL for customer development teams (larger number of systems > > for non-production cases). > > - Available no later than February 1 > > - Single Sign-on via a Red Hat account, or Github, Twitter, Facebook or > > other accounts (You'll soon not need to provide all kinds of personal > > information like you used to). > > I have same questions. > > This is copy of my email to centos-questions at redhat.com > > ============================================================================== > > Hello Red Hat, > > As I understand from the Red Hat blog article "New Year, new Red Hat > Enterprise Linux programs: Easier ways to access RHEL" I am limited to > only 16 no-cost RHEL instances. Limit 16 instances means bare metal > servers and KVM virtual machines, right? > > But what about systemd-nspawn OS-level virtualization containers? To be > able run "yum update" inside systemd-nspawn containers I need to > activate Red Hat subscription inside each container too??? > > And I can't have more than 16 instances (bare metal + VMs + containers) > with a RHEL subscription? > > This is too strict restriction for me. Because I use now CentOS 8 in > production and use systemd-nspawn containers for hosting websites, and > create for each website a separate systemd-nspawn container. > > Or I can legally create and legally "yum update" and legally use in > production OS-level virtualization systemd-nspawn containers without > activating RHEL subscription for each such container? > > But I still need to activate the RHEL subscription for each VM which > runs an RHEL instance? > > ============================================================================== > > 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.). 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. 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. [1]: https://podcast.asknoahshow.com/216?t=1877 -- 真実はいつも一つ！/ Always, there's only one truth!