Hi,
This is a follow-up main from recent discissions on #katello channel about relation between content
promotion and host group parameters.
Disclaimer: when using environment term here, I mean Katello environment. If I have Puppet environment
in mind, I will explicitly use the word Puppet. Puppet environment represent just a version of a content view
in specific Katello environment.
Let's consider the following use case:
As a reasonable system administrator, I tune the configuration and the software together in
development environment, therefore I use Katello content views for it.
Once I'm happy with the status quo of machines in development environment I want
to turn this changes into Production environment, including:
- software packages in the specific version
- puppet modules in the specific version
- hostgroup parameters the puppet modules
Currently, when promoting the content view, the packages and modules are moved to the
production environment. The question is how to get the parameters tuned for the new
version of content view into production. Additionally, there are some parameters
that should stay specific for the environment and should not be overwritten when
promoting new version of content view.
Possible approaches
···
===================- Puppet params aware content views in Katello
content views are aware of puppet parameters and host groups in Foreman
associated to this content view inherit from them, being able to override some of them
if needed. When content view is promoted, the hosts and host groups assigned to the
Puppet environment of previous version of content view will moved over to the
Puppet environment of new version of content view and and the parameters will be
inherited from the new version of content view as well.
- Host groups tied to the content views
when promoting a content view, all the host groups for this content view in Development
would be moved over to Production, replacing the old host groups for the Production hosts.
The question where to store the environment specific params, it could be probably solved
by smart params if it supported assigning them to Katello environments.
Alternatively, in host group every parameter could have a “non-promotable” flag, which
would not change in the promotion process.
Opinions, other approaches?
Additional issues
There is also an interesting question of how to handle multiple versions of puppet classes in Foreman,
especially when new version of a puppet module changes the class parameters, but it’s probably worth
another discussion.
– Ivan