We have recently merged Clone OS UI feature, this could be another nice one. Yeah. I’d do this via another UI feature, not automatically tho.
When we automatically create an OS, I think we should automatically assign the correct templates. This particular use case doesn’t make sense to require manual intervention.
Define “correct” please. Do you mean default templates?
Does that mean we’d allow the user to select any template and then perform steps 3-5 as part of it automatically as part of step 7?
Yes, on the new OS form show tab Templates, where we will list all templates, sorted by category. I have a proof-of-concept branch [0] for it, you can try it by yourself.
I’d prefer if OS had the templates pre-selected so users don’t have to think, which template to use when they create a new minor version of OS
This is is good idea, I could do it as a part of that PR I mentioned above
when an operating system is automatically created, e.g. by a fact import
To be honest this didn’t came up to my mind until you mentioned,
but it’s definitely good idea
Not sure how it should be modeled, but making minor versions optional would already be a step forward.
Minor version is already not required field, only required fields are name & major version.
Or are you talking about something else?
… this suggestion is aimed at reducing the number of times you need to make those relations so it may be in scope.
Good point, do you have any other ideas (with the idea about ignoring minor versions) that could make the WF easier? Including the idea to ignore minor versions for certain OS.
I think the reason why I personally did not start working on this was that we are building the new UI and once we get to the Operating System page, there should be a wizard that would guide user through the process and it would do this explicitly asking which templates should be associated and providing some best options.
I didn’t know about the new UI. Where can I get more information, or can I get involved? Sounds interesting to me.
So far it looks that most people are for the option of auto-selecting templates when creating a new OS.
Yes and no.
If the operating system is new, assign the default template specified in the template metadata.
If there is an operating system already (same name and family) present, copy the existing associations. I believe we can be a little opinionated here and assume that our templates work with a new version. In my opinion, we should encourage users to use the same templates for different operating system versions.
We currently have ansible playbooks that setup Foreman to work with a specific os release. So when e.g. RHEL 7.6 came out, we just added that so it works the same as 7.5.
As I mention above, I have POC-branch for selecting templates when creating OS. Here is a showcase of the feature:
Honestly, I don’t like a machine to be performing a heuristic find on how to setup provisioning templates, this can go bad quickly leading to some incorrectly set templates. I’d rather see a UI feature that would set templates via a button press so a human could review it.
What what you’re saying can be achieved by picking:
- templates from the same family OS which was
created_atrecently - or using default templates if none was found
Nice, I would not be against “learning from the past” approach Timo described above.
UI feature here is worthless for most users. The most common way for a new OS to be created is when facts are updated due to a new release. At least for me, the common workflow is that CentOS/Debian x.y is running, then x.(y+1) is released. yum-cron/unattended-upgrades updates my OS and now I have new OS in Foreman. Now I have to complete the info and clear out the old distros.
However, both CentOS and Debian don’t really care about .y versions. That’s why I argued that we should make it possible to not differentiate based on that.
@TimoGoebel’s proposal is to at least ease the pain by automatically filling in the missing data so you don’t have to go to the UI/API to fix things.
Those 2 solutions can both be implemented. Both because some distros (RHEL) do care about minor versions.
1 Like
Well at the moment there is a bug in Anaconda RHEL 8.3 which requires us to do a kernel command line workaround only for this particular version (8.2 is not affected). We need minor release numbers. It also has an inventory purposes (how many servers are still running on 7.0 etc).
I wonder why we actually need the OS association to by updated by puppet? It should have been either a different association or simply just a fact you can search. Because we will always the “fight” between what users set and what puppet reports back. The same for domain and subnet. We even have an option to stop updating them which indicate to me something is not right with this design.
Also, the auto-create feature is not very useful for provisioning because you still need to create a hostgroup for the new version. Don’t tell me you want Puppet to also copy-paste a hostgroup. 
I don’t know what’s the best thing to do and I am open to listening to our users. If we implement both UI improvement and puppet auto-creation I won’t block this. I just wonder if there is a bigger problem we are trying to mask here.
Right now you can’t provision CentOS 8.2. That’s why I said that for CentOS the minor version is irrelevant while for RHEL it is. There may be an exception for Katello where you can have content views.
So if you want to make my suggestion more concrete, I’d suggest a has_minor_version option on the Operating System model. We can suggest a default value. If it’s set to false, no minor version is tracked and the field is disabled (hidden?) in forms. In case you do have content views, you can set it to true, even for CentOS. In that case the old behavior would apply again.
All the same can be applied to Debian. There supported minor versions were dropped in Debian 4 but there can be content views.
For Ubuntu there are supported minor releases according to https://wiki.ubuntu.com/Releases. You do have 18.04.5. In this case 5 is the minor version.
That is indeed the point I’m trying to make. We treat minor versions as something that exists everywhere, but it doesn’t.
Isn’t just allowing minor version to be blank a better option than introducing a new flag? We can define this for each individual family then, e.g. for Debian we would not require it (actually we could enforce it’s empty) and for Red Hat we would require it.
Then it templates we can decide what to do depending on the situation.
Also, with CentOS 8 Stream, things might actually change. I am not sure yet how kickstart are published and ho woften, I need to try. Let’s actually find out, it’s December 15th 20:50 CET at the moment and this is the listing of http://mirror.centos.org/centos/8-stream/BaseOS/x86_64/os/images/pxeboot
[ ] initrd.img 2020-12-15 04:53 71M
[ ] vmlinuz 2020-12-03 22:24 9.2M
Looks like initramdisk has been refreshed today. Let’s revisit the link after few days, this would actually mean PXE files do have updates quite often, which is a big problem for us. This will break our wget -c download policy (continue = just append to existing file -> breaks). We need to fix this.
At the moment it would not be enough to allow empty as you can do so already, but then the configuration management report will come and create a new version including the minor and switch the host to this os.
I wouldn’t go that far. I think what @lstejska is trying to solve is another issue than you’re talking about. Issue 1) new user is lost when she tries to setup provisioning, Issue 2) existing user already has provisioning configured, but in combination with cfgmgmt, it creates new and misconfigured OS instances. While I agree 2) hits most of existing users, 1) hits every new user of Foreman. While I think we should also improve 2) this RFC tried to address 1) and imho it is absolutely worth improving.
I think we absolutely need to keep this feature and behavior. In my world, a user creates a new host, defines the desired os level (usually the latest available version from a specific major version) and then the host comes to life. During the lifespan of the host the version changes and you want Foreman und the UI to keep an up to date version for inventory, reporting and much more purposes. What I could imagine is that we prohibit a user to change the version in the UI while a host is not in build mode.
Why would a user want to change the version in Foreman and create a conflict?
Ok. So this is RFC is about a fresh Foreman setup. Imho the main question is: Why isn’t everything already setup for provisioning? Why does a user need to make any changes at all? What is missing?
Yes, that’s how I interpreted the first sentence. It could be even on existing setup for new OS family. But your question applies to this case too I think the thoughts about this have always been, we don’t want to clutter the app with data people won’t use. E.g. we don’t want to precreate RHEL 7, RHEL 8, CentOS 7 and CentOS Stream 8 in case the user is Debian shop (and vice versa). However I’d be more than happy to see kind of foreman_setup v2, where I’d say I want to be able to provision e.g. Ubuntu and that would define all that I need. Of course it would need to ask more questions.
Perhaps, before we go that far, we could just pre-select the default templates on OS creation form. Perhaps the same for partition table, installation media and architecture. Or we could have some rake seed_with_examples task (like redmine has) that would pre-create “Debian example”, “CentOS example” OSes, that people could clone (new feature recently merged) and adjust just the versions.
Anyway, all of this I think is orthogonal to what we can improve right away. If we improve the form without changing anything on the backend, it’s already a big win. I refer to option 2) of this RFC, the experience would be like on the gif. User selects the template, backend does create both associations if needed. If we preselect value in the form, even better. Perhaps we could add a warning, telling the user that this will also enable the template for OS automatically to avoid unwanted “mis-assignments”.
It is probably a different discussion, but honestly I like the idea of pre-seeding some major OSes. What’s a bit messy are RHEL clones - this can quickly get out of control.
A rake task is not a bad idea at all, maybe it could even do some stuff from the half-abandoned foreman_setup which I never liked. Maintaining a plugin just to perform an initial configuration never sounded to me. If you know what I mean.
I concur. Can we make the selection or form a little intelligent?
Ohhh it’s animated gif! Now I understand… jeeez.
How much smarter would you like to go than what’s shown at [comment](RFC: Operating Systems and Templates gif)? You must click on it to see the animation. My understanding is, on OS creation, we’d display all kinds and all templates for each kind. If I pick template x and save the OS, it associates the template with newly created OS and it selects that template for the OS in one action. The other smart thing may be to preselect default templates after we chose the OS family, however I may not want to chose a template for each kind. Do you have any other suggestions for the form?
To be honest, I don’t get the animated gif. I’ve watched it several times now, but that does not help.
Let’s imagine I’m a novice user and fire up Foreman for the first time. The first thing I do is to create an operating system. I believe the current tab would be pretty overwhelming. I think we should filter the possible options based on the chosen os family (note that we have that data available in the metadata) and add some inline explanation in the templates tab (why they are necessary, what they do).
That the associations are created on save is a very good thing. I’m totally in favor of that.