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