How many lifecycle environments?

Support
1

Hi,

usually, you only have “dev”, “test”, “stage” and prod, right?

But… we are an MSP and will potentially be supporting dozens of customers, each with test and prod (and sometimes stage and or dev). Well, sometimes they only have prod (or test, like in the meme…).

Currently (sans Foreman/Katello) we basically try to patch every quarter (often every other quarter, except for special cases were we really need to patch more often).

We have a local mirror that is updated weekly and every quarter, a new directory with hardlinks is created.

To patch, we run an ansible playbook that updates the quarter in the repo-definition.

Every customer (still) has their own patch-schedule (open ticket, inform customer, set time, snapshot, patch test, verify with customer, snapshot, patch prod, verify, delete snapshots, done - rinse, repeat…)

Now, when I use Foreman, I have to create an activation-key for each lifecycle environment.
Instinctively, I would want to reduce the amount of lifecycle environments, as to not create a plethora of activation keys.

But then, the lifecycle environments would need to be really big (we’ve got basically everything: RHEL (and most the forks (Alma, Rocky, Oracle and CentOS7 for the time being…), SLES, Ubuntu, Debian and also stuff like FreeBSD that you can’t even have in pulp…).

So, these lifecycle environments would need to contain basically all of these - even though only a fraction is needed each time.

This somehow does not “feel right”.

Additionally, I can see problems where I promote a newer version of the Content View (because I need it on a new install or because a customer insists) even though I don’t even want to have it somewhere else. Even worse, when I have to update (promote a new version to test), while I have only partially update all the prod servers with the previous version rolled out on test…

OTOH, creating all the lifecycle environments with specific repos also looks like it gets “interesting” quickly enough.

So, what do people do?

2

By design, if two sets of content hosts, should not be getting new content at the same time, they should not be in the same lifecycle environment. In your case different customers should quite possibly be on completely separate lifecycle environment paths. So you might have the following lifecycle environments/paths:

Library > custumer_a_test > customer_a_prod
Library > customer_b_test > customer_b_prod
Library > customer_c_prod # This customer does not have any test systems

Then you can promote for example only version 20 of your “Ubuntu CV” to customer_a_prod, and customer_b_test as needed, while customer_c_prod is still using version 12 of that same content view. And Alma content views remain unchanged. etc.

Is this a workable solution, or am I missing something obvious?

1 Like
3

Thanks - It’s basically what I suspected since I looked closer at it.

Eventually, the actual chore of promoting to so many LCEs can be at least semi-automated with hammer. So it’s just optics.

4

Another thing I noticed when I started to amass lifecycle environments:

Could a radio-button be introduced in the GUI to hide lifecycle environments (in the Activation Key “details” tab) that aren’t used?

I have created ansible playbooks to automate the creation of host groups, lifecycle environments and activation keys, so I don’t see myself venturing too much into that part of the GUI - but when we end up with a very long list of them, it’s more confusing than helping to have all of the listed there.