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-program...
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@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?
More details here:
- https://www.oracle.com/linux/
- https://linux.oracle.com/switch/centos/
==============================================================================
[...]