Change life cycle path/order?

Problem: Is it possible to change the life cycle environment progression path? The developers insisted that they wanted the progression to be library → test → development → production. So, that is how we created them. However, they are constantly asking us to provide new software to their development servers before even running on the test servers. As I expected all along, I think we need to swap the order of test and development. Is this possible, or will I have to re-install from scratch?

Expected outcome: quick change to the life cycle order is achieved

Foreman and Proxy versions: foreman 2.4.1, katello 4.0.3

Foreman and Proxy plugin versions:

Distribution and version: CentOS 7.9

Other relevant data:

Afaik, switching lifecycle order is not possible.
But you also do not need to reinstall everything. You can create a new lifecycle path from the lifecycle environments page, create new lifecycle environments there and move your machines to the new environments. While still being some work (especially if you have a lot of systems) most of it should be easily automatable.
You could also just roll with it and promote changes to development before testing with you current setup, lifecycle paths are not an enforces rule, more like a suggestion. This might be ugly and counterintuitiv, but it is the low-effort version of what you are asking for :wink:

OK. Thanks. Instead of updating from 2.4 to 2.5 to 3.0, we are thinking about just installing 3.0 on a clean vm then just update the clients. Might just change the order on the new system. If not, creating a new lifecycle path should not be that hard.


Glad I could help!
If you are satisfied with my answer, would you please mark it as solution so that others can see this topic is solved? There should be a checkbox with the text “solution” at the bottom of my post for that :slight_smile:

I think I marked it.

Do yourself a favor, automate the configuration with the Ansible modules :slight_smile:

That way you can also make a duplicate in the case you need to test it, or if it breaks for some reason, you don’t need to spend another day rebuilding it :slight_smile:

I like ansible, but the rest of the team is married to salt. Will have to discuss the lifecycle progression with the developers. :slight_smile:

I’m not familiar with how salt works, but if you can have it work the API, that could also help you out :slight_smile:

There’s always salt.modules.ansiblegate although I never messed with it myself so ymmv.