[CentOS-devel] First round of RHEL programs announced

On Fri, Jan 29, 2021 at 6:30 AM Gena Makhomed <gmm at csdoc.com> wrote:
>
> 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?
>

Well, strictly speaking, you only need to do this if you cut off
subscription-manager from the host's registration. There's a hook in
Podman that pulls in the host RHEL subscription entitlement into the
container so that everything works without registering a new
entitlement (as permitted by the terms). You'd need to do something
similar for systemd-nspawn to qualify it properly as container usage.

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

Strictly speaking, it is not forbidden for use by companies. It's
forbidden to *register* to companies. That means it *must* be tied to
an individual, and if that person leaves the company, those
entitlements go with it. It's deliberately designed this way so
someone could do a startup with RHEL and scale up eventually to proper
commercial licenses if successful. This was a specific example the
Brian said was permitted in the Ask Noah Show interview[1].

[1]: https://podcast.asknoahshow.com/216?t=1877

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

VMs require separate entitlements, containers do not. Describing
nspawn as a VM probably confused Brian, it is explicitly not a VM
technology, as it can't boot a kernel or simulate hardware.

But this circles back to my hope that RHEL subscription pricing can be
improved to support a broader base.




-- 
真実はいつも一つ！/ Always, there's only one truth!