5 ms·

And those conditions are exactly what the OP meant by a licensing game.

• prmoustache 3y ago
  There is notting in Jeff Geerling's project list[1] that warrant hundred's of rhel machines and containers at any given time. Containers are mostly ephemerals when used for build and test purpose. [1] https://www.jeffgeerling.com/projects https://www.jeffgeerling.com/projects
  • geerlingguy 3y ago
    The fact that I have to spend more than 5 seconds considering how to integrate my Red Hat Subscription into my test builds (for dozens of projects) means I won't do it. That's why I stuck with Rocky Linux instead of just dropping all RHEL support entirely. And there are _a lot_ of test runs where I have more than 20-30 test containers running simultaneously with Rocky Linux 8 and 9. Do I have to write new software that limits my test infrastructure to only run 16 tests at a time or something idiotic like that? Do I have to even wonder about that using Debian, Arch, heck even Amazon Linux? No.
    • prmoustache 3y ago
      > The fact that I have to spend more than 5 seconds considering how to integrate my Red Hat Subscription into my test builds So basically you are saying the author of an ansible book do not care spending a couple of minutes understanding a simple process to automatise it. Sounds like great advertising for your books really.
    • yrro 3y ago
      FYI containers aren't their own entity for subscription management purposes. A subscribed host can run as many containers as it wants, the host's subscriptions work inside the containers. (That said I agree that dealing with subscription-manager at all is a lot more annoying than ... not having to do so with RHEL derivatives!)