Split Host Groups and Puppet Classes / Ansible Roles


#1

AFAIK most tabs of Host Groups are only used during host provisioning. Only a few tabs are later on used to configure already running hosts. In my point of view, only the tabs Puppet Classes, Ansible Roles, Salt States and Parameters are used after provisioning a host and take affect without rebuilding a host. In case a setting like “Network->Domain”, “Host Group -> Content View” or “Operating System -> Architecture” is changed, this change doesn’t affect already deployed host. Only if you rebuild them. Please, correct me if I’m wrong.

Therefore, wouldn’t it make sense to:

  • Move Parameters, Puppet Classes, Ansible Roles and Salt States to something like “Config Sets”. The behaviour of Config Sets would be similar to the current Host Groups - including to have sub config sets etc.
  • Rename Host Groups to “Host Templates” in which it is possible to select the Config Set which should be used if a host in this Host Template is provisioned

Afterwards, it would be crystal clear for evey user, that all settings of Host Templates are only used during provisioning and Config Sets take affect for already deployed hosts, too.

What’s your opinion?


Rethinking host groups
#2

Overall, +1. However, we do also have the Config Groups feature, so we’d need to be careful about not conflating the two. @Roxanne_Hoover, thoughts?


#3

In general, I think this is a step to right direction. Could we perhaps reuse
config groups that we have already? Or do you see config set as 1:n hosts
only, same way as hostgroups? I can imagine that we’d like to keep it simple,
this way we don’t have to figure out the order of puppet classes and hence
smart variable/parameters priority. Though if we’re touching this, and
potentially change the hostgroup API (I guess that would mean v3 anyway), we
could fix it too.


#4

+1 on the direction and also for reusing/altering config groups for this purpose.


#5

I guess, reusing config groups does totally make sense. The question is:

  • does config groups need to have a hierarchy / sub groups
  • should we have parameters on config groups AND / OR in “Host templates”

#6

Optional I think. I can see an argument for “Monitoring role” being a sub-config-group of “Webserver role”, but it’s a nice-to-have.

There’s the issue - today Config Groups cannot have parameters, by design (so that multiple config groups can include the same classes without conflict). There’s a need for that and a need for groups that are 1:n and have parameters attached.

Definitely AND :slight_smile: - Provisioning-related parameters make sense here. But do you mean general Foreman params, or specifically Puppet params? (oh English overloading, how I hate you …)

Would be good to hear @Ori_Rabin / @kgaikwad thoughts on this…


#7

Thanks for bringing this up!
I definitely agree that the current hostgroup workflow is problematic, and often users are confused by it. To elaborate on your description, a hostgroup right now is actually a mix of two different use-cases:

  1. Provisioning configuration - these attributes are copied to a host on creation. If they are changed on the hostgroup, they do not affect existing hosts. These attributes also have an additional complexity point, in that they may be changed when host facts are imported, possibly rendering rebuilding the host impossible without manual intervention. Right now, there is no way to change these attributes in runtime en bloc for a hostgroup - e.g. move an entire hostgroup from one domain to another.
  2. Runtime configuration - for these attributes, a host includes the hostgroup attributes and sometimes overrides them (e.g. in the case of parameters). Changes made on the hostgroup level will affect all hosts in that hostgroup.

Parameters are a bit of both - since they can be used both for provisioning and for configuration management, so I wonder if they might need to be present in both new objects? Or perhaps there should be separate provisioning and runtime parameters?


#8

I wonder what’s the use case that we are trying to solve?

There are two possibilities with different approaches:

  1. We want to select certain features from the hostgroup, but each host should belong only to one such group. For example hosts A, B and C belong to HG1, but A uses only provisioning properties, B uses only configuration properties and C uses both.
  2. We want to mix and match groups, meaning we want each host to select its provisioning group and configuration group separately. For example hosts A and B will have the same provisioning properties (both bare metals with the same OS but one is a DB server and the other a web server), but hosts B and C share the same configuration (both web servers, but one is a bare metal, and one is an amazon VM).

Both solutions have their advantages and disadvantages, so we need to understand which way do we want to go.


#9

+1

By considering fact that there must be parameters which are specific to provisioning ONLY then AND required.
But along with this change, we will have to consider parameters priority in hostgroup again.

As @Shimon_Shtein mentioned, there might be different approaches using provisioning parameters and config groups.