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!