I’ve been excitedly following this discussion! I know this is a developer forum, so I don’t want to distract you, I just want to interject a few quick comments on things that really resonated with me.
This would make things so much easier for a Foreman beginner. It’s a great idea!
I completely agree with you. There were three main reasons I had to put my Foreman deployment on hold (aside from needing to build things to bring in revenue). The first was the fact that everyone I talked to said that they deploy Foreman as a pet. I started writing an installation script for my particular situation, but I wasn’t able to get all the way to a fully working system, before I had to move on.
If I had a consistently repeatable way to deploy Foreman and a mechanism for migrating data from old to new, I would feel far better about picking it up again.
Above I mentioned “three main reasons”. The other two were:
The getstarted.theforeman.org idea for generating a config sounds like a good place to start. @Marek_Hulan started down an interesting path with Spark. The original RFC that seems to have sparked that effort, is still just as relevant today.
I am very interested in the idea of reducing Foreman’s scope. It came into being at a time when there was a paucity of tools, so by necessity it had to do everything. However, things are different now. Perhaps it makes sense to begin replacing some of Foreman’s existing core functionality with plugins?
There still aren’t many good open source tools for building bare metal, so perhaps that remains a Foreman core competency.
Someone, earlier in this thread, said that Foreman is more like a framework, so maybe moving it in that direction would be worthwhile? It could become the tool of choice for bare metal deployment and visibility at that layer of the stack and then a framework for integrating the other tools necessary to manage the layers on top. This idea hints at @TimoGoebel’s idea of packaging up puppet and r10k into a known working state and deploying that in a way that plays nice with Foreman.
Thanks for chiming in! Despite this being a development forum, user inputs are super valuable for the developers to know we are heading in the right direction. Please feel free to take part in any discussion here and offer your insights 
Can you elaborate this more? I am not following.
One of the questions would probably resolve the problem of scenario - katello or foreman. Obviously some questions would be irrelevant for foreman scenario or vice versa - there must be some dependency of some kind.
Yes, this. I also believe we are weak in integrating with clouds. I’d ditch this to be honest and invest resources in other areas.
Actually this is the problem we are trying to solve here. We should keep it as “open core” and “plugins friendly” and even more push on better integration (new generation foreman hooks plugin) but we should strip down those features we are weak at or those which do not work well.
Our forum sections disencourage users from reading here. Development or Support. Make your pick. But where is the place for generic users talk? We don’t have any. I vote for creating one.
We actually have one - Community. should we move this thread there?
Yes, can we move it up in the list when you click on Create Post? It’s at very bottom, I think the order should be:
I’m a big proponent of creating an entirely new foreman (and katello) UI that uses patternfly 4 and addresses many of the problems of the current UI by offering opinionated workflows. We could even have the current UI be the “advanced mode” of this easy to use UI at least at first.
In my opinion, every time a user has to refer to the documentation it’s a failure of our UI but I’m glad it helped you (also welcome to the forum 
).
IMHO you need to start with designs how it would look like before making that decision, just “creating a new UI” won’t fix much - I would not start without a SME (and probably a dedicated UX designer) to design the ideal / practical workflows
IMHO you can start with a standalone UI to just to play with things (research experiment) but I totally agree you need to have a vision before building something that you intend to ship.
we have the lab features where you can easily create a brand new workflow
and the commit bar is lower, or in other words, I don’t think that its a
lack of ability with the UI vs what exactly should we build
I agree with both of you on this. Definitely need a dedicated designer and other stakeholders to collaborate on this.
I don’t quite follow the second sentence but I think we could use the lab features menu but that the code itself should live in an entirely new repository.
I’d be very surprised if outcome of any UX reserach is different than:
I’ll add to that:
Designing any other pages is IMHO wasting of both time and resources.
I would add as one of the worst workflows we should improve assigning templates to an operating system.
Especially annoying if you update a system which gets a new operatingsystem release. In this case it creates and assigns the new operating system to the host and makes redeployment impossible until you go to provisioning templates and assoziate them with the operating system and afterwards go to operating system and pick them as default, assign the mirror and added parameters.
So it is a bad workflow at all, and it would be even better if there was no need to do it at all because it could just automatically copy from the older version of the operating system. If adjustments are needed later it would still be easier in this way.
This has actually been mentioned several times in the last community survey, and fixing it is probably very low hanging fruit that doesn’t require a whole new UI - just a fairly small change to the existing forms.
For orcharhino installations we provide a web based installer.
The installer queries some data from the user and save the required information inside a yaml file.
The yaml file is used by an ansible playbook to do the installation and starts foreman-installer with all the needed options.
If you’re interested we could start open sourcing the installer and work together to improve it further.
Please have a look at some screenshots from the documentation:
https://docs.orcharhino.com/sources/installation_and_maintenance/installation_guide.html#main-installation-steps
For what it’s worth, kafo_wizards was started in 2014 but nobody picked it up and finished it. Now people are suggesting to build an entirely different system just to drive the installer. That doesn’t make sense to me because who is going to maintain that? I suspect if someone builds a getstarted.theforeman.org it’ll have the same issues as foreman_setup where things break and nobody notices for a long time because it’s not tested.
Earlier this week during a conversation it came up that installer might be a bad name for the project, especially in the Katello scenario where it is also used to upgrade. Installers are typically only used once so that sets the wrong expectation.
This is a good point, whether its docs or a tool to manage the installer or a combination of both, it should be tested or it will become outdated and unreliable. The testing effort and tools being worked on can help this effort.
I’ve often thought this, it feels weird to run an installer to update options and configurations after you’ve installed the software with it. I wonder if this has been a point of confusion for a lot of users, it wouldn’t surprise me to hear this. Maybe a name like foreman-configure would be better?
One thing to ask is how have other dev teams reduced the complexity in their applications? We could stand to not re-invent the wheel, so if there are proven paths out there we could benefit from learning from them.
Its not a perfect parallel, but I know React was a huge pain to set up with a webpack config before create-react-app was created. This opinionated layer made it much more approachable and easier to setup (I wouldn’t dream of starting a React app without it). You can also “detach” your application from being managed by it and then be on your own if you would like to own the configuration. So this is a good example of introducing an opinionated tool to help manage a complex setup.
How about starting with the design first and not worrying about the implementation until the design is figured out? I know this is hard for us engineers to do… but starting with what we would like our UI to look like without worrying about technology restrictions may be the best way to approach things. Once the design is finished, then the implementation can be discussed.