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.
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.
Ok, that totally makes sense. So to rephrase, you’d add to that PoC
filtering of displayed templates based on OS family selected in the first tab
adding a label text to every template kind to explain what’s that good for
The 1) is a bit complicated, but definitely would be very valuable. It’s not possible for all kinds unless we introduce OS family to provisioning templates as mandatory attribute. However I’m not sure how to auto-detect that for custom templates, which we’d need for upgrade of existing installations.
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.