[CentOS-devel] First round of RHEL programs announced

Hi Brian,

On 28.01.2021 23:38, Brian (bex) Exelbierd wrote:

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

Situation with RHEL UBI is clear, and I don't ask about them.

My question is exclusively about systemd-nspawn containers.

https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html

systemd-nspawn containers provided in RHEL by systemd-container package.

> If you run the registration inside of the container,
> that will count toward your 16 entitlements.

Yes, I understand what if I run the registration inside
of the container, that will count toward my 16 entitlements.

My question is this:

Is it legal to use RHEL inside systemd-nspawn containers without
registration and without activation subscription inside the container?

Do I need to start the registration process inside each container,
or will the "yum update" command inside the container work without it?

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

Are you talking about the announcement on 1 February
"No-cost RHEL for small production workloads" ?

Surprise!

Developer Subscriptions allowed to use for production workloads
only by individuals, and totally forbidden to use by companies?

: We’re addressing this by expanding the terms of the Red Hat Developer
: program so that the Individual Developer subscription for RHEL can be
: used in production for up to 16 systems. That’s exactly what it sounds
: like: for small production use cases, this is no-cost, self-supported
: RHEL.

"can be used in production for up to 16 systems"
- I didn't find here forbid to use by companies.

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

Conversation about what?

no-cost RHEL as I understand is forbidden to use by companies.

350 USD/year RHEL is forbidden to use for virtual machines.

800 USD/year RHEL is too expensive for each bare metal / VM / container.

Website hosting is low-margin businesses, it is unreal
to pay 800 USD/year for each virtual machine/container.

One hosting server can have several dozen or even several
hundred of virtual machines or systemd-nspawn containers.

As I understand, there are only two available options for me:

1) Migrate to Oracle Linux, Alma Linux, Rocky Linux.

2) Migrate to Ubuntu / Debian / some other distro.

-- 
Best regards,
  Gena