In most cases it is the git workflow with branch, merging, …, which is more flexible than the audit which only show changes and do not allow revert. In more and more environments there is als some usage of CI/CD to test, review and deploy which allows also for complexer environments like multi-master or different masters per department or similar.
That’s good to know. It’s probably out of scope for this discussion but soon we should have one about the use of Puppet and future integration.
I guess we’ve already entered post-Puppet era.
Many interesting poins were mentioned here. I do not think we should use hostgroup in the new host wizard at all. There are too many unrelated things attached to it which does not help us in simplifying the workflow but rather leads us in direction of ‘how to turn existing host form into wizard’.
I do like the idea of host template/blueprint as @lzap mentioned but I do not agree template/blueprint should be an existing host for the reasons already mentioned. Moreover, we have that feature already - just click ‘clone’ button on host show page ;-). This also ties to what @tbrisker proposed for hostgroups - separating various parts and distinguishing between configuration in Foreman and what is reported in facts. In this regard, host template/blueprint is a bit misleading name because it would deal only with provisioning and would be one of the hosts aspects (I intentionaly avoid word ‘facet’ here, though existing facet framework looks like a good fit but I leave it to @Shimon_Shtein to confirm). Creating a host from a template/blueprint (just one type for start, regardless of whether it is virtual or bare metal) seems like a good candidate for the first version of hosts wizard to me.
<offtopic>It would be nice to create a template/blueprint from an existing host though.</offtopic>
I see a host as a composition of ‘funcionality/feature groups’ that may or may not be present regardless of implementation. This is useful for extensiblity, because on one of the first steps in wizard could be a set of questions like the following:
- Would you like to use Puppet with this host?
- Would you like to use Ansible with this host?
- Would you like to use Openscap with this host?
- Would you like to subscribe this host to consume content?
Based on the answers, steps could be ommited, which would satisfy the requirements for a short wizard. This is in line with previous suggestions. I just wonder how well this plays with @TimoGoebel’s suggestion about admin and user who installs systems.
I see the suggestions for bare metal capabilities as the first worflow that we should go for. Any other thoughts?
1 Like
I think we’re making progress here. My point is, that the questions you listed above are usually questions you ask once. And not for very host.
Can you think of a scenario where a Foreman user would answer these questions differently for each host? I like them, but I think they make more sense in a setup wizard (or to create a blueprint that you can create a bunch of hosts off of).
1 Like
I can’t think of a scenario where these questions would be answered differently for each host. I think they would be answered differently for various groups of hosts.
It ultimately comes down to how much customization the user creating hosts wants/needs to do. If the workflow could be summarized as “I want Foreman to create a host that has X and Y using as few clicks as possible and I do not want to configure details myself”, then blueprint is a good place to put those questions.
With a blueprint, we could have 2 wizards that would be optionally chained together:
One possible concern with having a highly configurable blueprint and few options to configure in host wizard is having a state explosion in blueprint. I do not know how many different groups of hosts users usually have. I suppose if someone wants a host that is just a little different, it is convenient to clone and modify in hosts form, but that is just my guess.
2 Likes