Following my call to simplify Foreman, I think that host groups pose one of the main points of confusion and complexity today.
Host groups are complicated objects that serve (at least) two very different workflows:
- As a “template” for a new host, which is used during provisioning to pre-define some or all of the attributes of the new host. These attributes are either copied to the host or retrieved from the host group during provisioning. To make things more complicated, some of these are later overridden in the host object by attributes reported during fact processing, making rebuilds with the original configuration difficult and confusing. Changes to these attributes after a host is built in most cases have no effect on hosts in the host group.
- As a block of configuration management options, such as puppet classes to apply, ansible roles to execute and various variables and parameters related to them. These are applied during runtime and changes to these on the host group level usually apply to hosts in the host group.
- Are there other use cases I’m not thinking off? Please comment below if you have others.
My proposal is to consider breaking them up into two separate entities (better naming suggestions welcome):
- Host template: this will contain all settings needed for provisioning to work. It will remain attached to the host after it’s built, so that when rebuilding the user will be able to select whether to rebuild the host from the template or from its current attributes. The host attributes will only reflect those reported by the host and will not copy values from the template, eliminating the need for multiple settings for ignoring certain facts. It may also make a host wizard (such as was proposed here for example) much easier to implement.
- Host configuration group: this will contain a set of configuration management related attributes - such as puppet classes and their respective parameters or ansible roles and their respective variables. Changes to these will impact all hosts assigned to the group. Perhaps they can also be connected to host templates so that a new host will get these executed after provisioning? Maybe we can leverage the existing config groups object for this?
I didn’t go into too much details on purpose, because I would first like to get some feedback from both users and developers regarding this direction. If and when we agree on the direction we can start breaking it up into stages that will eventually lead to the desired outcome without (hopefully) disrupting existing workflows too much. If you think this is not something we should invest any effort in, please also say so below, and I’ll think of something else to do in my spare time