Hey Lukas,
thanks for the chat at OSAD.
Do you use hostgroups?
Yes
What are the features you like?
Gives us the possibility to create templates in a way that a minimum set of values have to be entered for deployment(Name,Organization, Location and HostGroup). Thus, the actual deployment of new host is possible for everybody. No detailed knowledge of items like target cluster, networking, storage,vcenter, or OS Minor Version or anything else is required. This also ensures a high level of standardization and orchestration for each required level. We use for our BareMetal installation AutoDeploy Rules that also depend on Hostgroups settings.
Our configuration ended up in more than 70 Hostgroups with a level of max 5 nested. So Inheritance is an important feature for us. OS Minor Version, Subnet Changes, New Parameter… is minimized to 3-4 Changes…
- Parameter Settings within hostgroups
Our hostgroups are configured by a data center administrator in cooperation with the actual target department. Any other employee is enabled to create new hosts based on these templates without any need of deep infrastructure knowledge. For us, it enables automated integration with applications and clusters as well as integrating extensions for load balancer environments. The parameters are further evaluated in our Kickstart/Snippet templates which enables us to use a single Kickstart file for many different scenarios.
Not every user can access all hostgroups. This allows us, that the teams can only deploy hosts following a preconfigured template in order to keep the standards upright.
Our hierarchy of hostgroups is designed like that:
OS/ApplicationType/Environment(Prod/Stage/Dev)/[detailed purpose/location ]
e.g.:
CentOS6/PHPApp/Prod/behind_LB/phpapp-websng/
CentOS7/Integration/dev
CentOS7/Integration/prod
CentOS7/Integration/stage
OracleLinux/DB/DNFS/Stage/RZ1
OracleLinux/DB/DNFS/Stage/RZ2
OracleLinux/PostgreSQL/Prod
Windows/2012R2
Windows/2012R2/Prod
Windows/2012R2/Test
ESX6.5/CITRIX/RZ1
ESX6.5/VM_PROD_LINUX
RedHat7/SAP
What features you don’t like or use?
We do not use puppet class configuration inside the host templates. Instead, we use PuppetFacts within our Kickstart templates (PuppetRole, Clustername,….) configured by Parameter within the hostgroup. The rest is triggered by the Puppet Server itself. From our point of view, this is a good option to avoid problems of understandings as changes will not be applied immediately to all hosts as opposed to managing them within foreman.
How would you approach this problem? Different concept? More fields or less fields in hostgroup?
In order to get rid of problems of understandings, an easy approach would be to mark all fields accordingly (e.g. by selecting a special input color or whatever) or let the user do an additional commit (All changes will be applied to running hosts immediately – you you want to proceed?) or something similar…
In general I think it is never good for a general acceptance to discontinue features rather than hiding them from the first view. Even if alternatives might be interesting, for a large group of users, the world outside is more complicated, environments are complicated and becoming more and more complex everyday demanding a solution that does not only work with kind of simple to follow but also allowing for a high level of flexibility.
Susanne