[CentOS-devel] First round of RHEL programs announced

Thu Jan 28 21:38:59 UTC 2021
Brian (bex) Exelbierd <bexelbie at redhat.com>

Hi Gena,

On Thu, Jan 28, 2021 at 12:23 PM Gena Makhomed <gmm at csdoc.com> wrote:

> This is copy of my email to centos-questions at redhat.com

This is in my queue - sorry for not having gotten back to you yet.
I'll reply here for some of this.

> ==============================================================================
>
> 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?

In general yes, containers, as mentioned below are a bit ambiguous
without some definition.

> 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???

RHEL UBI containers when run on an entitled RHEL host do not need to
be separately entitled and do not count toward the 16 entitlements.
This is part of the set of "super powers" RHEL UBI gets when run on
RHEL.

If you run the registration inside of the container, that will count
toward your 16 entitlements.  For example, running a RHEL UBI
container on a non-RHEL host where you wish to access the additional
content available with your subscription.

> And I can't have more than 16 instances (bare metal + VMs + containers)
> with a RHEL subscription?

The Individual developer subscription is limited to 16 entitlements.
There are other subscription models that have more.

> 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?

Virtual machines need to be separately entitled.  They count toward
the 16 entitlements.

More generally speaking, anytime you register you consume an
entitlement.  This is one huge advantage of using RHEL UBI on
registered RHEL hosts.

> ==============================================================================
>
> 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.

No.  The Individual Developer Subscriptions do not accrue to a
company.  Companies do not get to use this program.  As others have
pointed out, doing this will create management nightmares and
liability concerns.  When the terms and conditions are released you
would need each individual to study them in detail to determine if
they could be part of this amalgamation that you are proposing and
still be within the terms of the legal agreement they entered into.

Red Hat believes that in the situation you describe a company would be
best served by having a conversation with a commercial provider to
find a good fit for this workload.  Obviously we'd like that to be
with us about RHEL, but we understand that other options exist in the
market.

regards,

bex

>
> 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/
>
> ==============================================================================
>
> [...]
>
> --
> Best regards,
>   Gena
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> https://lists.centos.org/mailman/listinfo/centos-devel
>
--
Did this email arrive after work for you?  Stop reading it and enjoy
some work/life balance.

Brian "bex" Exelbierd (he/him/his)
Community Business Owner, RHEL Product Management
@bexelbie | http://www.winglemeyer.org
bexelbie at redhat.com