I’ve seen several threads recently discussing how hard it is to deploy Foreman. I also feel upgrades are not always as smooth as one would hope, especially when installed with many plugins. So I thought it would be a good time to share what I’ve been thinking about for a while. First, let me try to describe the state I’d like to get to.
Installing Foreman should be as easy as running an installer with not more than 5-10 parameters. Installation will provide minimal setup of Foreman that will allow to install and deploy additional features. The configuration and further maintenance is made from this Foreman instance. Few examples - user decides to configure provisioning. They fill in required fields in UI, e.g. type - network based provisioning, smart proxy used for such setup, IP range, domain, etc and click submit. That will ensure the correct setup of dhcp, dns, tftp services and also creates required objects such as Subnet and Domain in Foreman DB. Later after Foreman is upgraded, we should also automatically detect, whether a smart proxy is compatible with current version and if not, we should provide a way to update it, again with an easy of clicking a single button. The same concepts should apply to installing additional plugins (including Katello) and upgrading Foreman itself.
After several discussions we had on the provisioning setup, you may now think, well it’s more complicated than that. There are many variations of provisioning setup that users do. I’d propose focus on those we know are most widely used and provide setup helpers only for them. While we shouldn’t prevent users to reconfigure their instances according to their needs, we should become more opinionated on how we recommend to setup Foreman and potentially what we support.
Good thing is, we have all we need. I see Foreman as a great framework to build and configure basically everything. We just need to identify most common use cases and make them simple to achieve. We have powerful orchestration framework, we have integration with several configuration management tools, we can provision additional hosts so all we need is to start using them and wrap it in nice UI. So how to get there?
Step 1: Installer
Our existing installer has huge amount of parameters. Yet it’s limited e.g. in terms of configuring provisioning, it only support single network. Hiera configs can be perhaps used for other, but it does not feel as “easy way to configure”. Adding more parameters to installer does not make it easier either, today we have several hundreds of them and we see users struggle with it. It also often cause confusion when we rerun it during upgrade, as it overrides configuration files user modified, without any warning.
This approach worked for a small app we started years ago, but it may not be the best option anymore. It’s hard to configure everything correctly from the very beginning. So I’d like to offer alternative which should help with initial deploy.
I’d like to have a simple, very opinionated, quick install tool, that will install Foreman core, internal smart proxy with just basic set of features and plugins required for further configuration. I’m thinking of foreman_ansible - in fact that brings also rex and tasks as dependencies and next generation of foreman_setup. It would only ask for SSL certs paths, admin credentials and that should be it. This should give user a minimal setup, that can be used for adding more features to the Foreman.
This does not aim to replace existing foreman-installer which is still a great way to do e.g. automated setups for users, who know all answers before they start. This aims to make it easy to deploy Foreman, start with simple setup, experiment with additional features. Mainly new users and users with an easy use case, such as cfgmgmt dashboard, should benefit from this mostly.
Step 2: Configuration of additional features
It’s not easy today to configure advanced features, such as provisioning. Users run the installer and need to figure ~15 parameters the hard way in advance, then they need to replicate some information in Foreman UI too. Also installing a plugin is advised to do via another installer run while the configuration then usually happens inside of Foreman. We should focus on make this as easy as possible.
There is a foreman_setup plugin which aimed to help with provisioning setup. It was built before rex/ansible integration was available so it ask user to run some steps manually on the Foreman host. We can improve this flow and never ask user to leave the UI in order to finish the configuration. Also the UX of wizard could be improved with technology we have available in core today.
The similar aproach from foreman_setup should be added for other things, such as adding new plugins. Usually that shouldn’t be more complicated then installing few packages, doing some configuration and restarting Foreman. Obviously the hardest plugin to add to existing setup is Katello, because of many backend services, but it’s not impossible. The catch might be SSL setup as we wouldn’t be able to rely on puppet CA anymore and we’d probably need to orchestrate certificate requests and signing somehow, but that’s another thing that deserves more improvements for a long time. Given plugin installation requires Foreman restart we should also look at how to improve maintenance mode of the app.
We can start easily with shipping some playbooks implementing the above. Then we can extend foreman_setup that will add nice UI on top of it.
Step 3: Maintenance of Foreman installation
Today if some backend service such as smart proxy does not respond, we usually display ugly 500. This could happen due to network issue, old version of some smart proxy plugin, bug in code etc. We should change our approach and always write a robust code that would detect issue before it tries to do something with the backend. In case the backed does not work, we should try to detect the cause and provide hints to user or even better remediation. We should always check the backend version and ensure it’s compatible. And if it’s not, we should ideally offer a way to upgrade it. Imagine a button that would trigger rex/ansible job to install newer version of smart proxy plugin and restart the proxy. If we take similar approach for every isolated part of the system, we could do the full maintenance within Foreman only. The only service that probably can’t be easily maintained this way is Foreman itself.
While all steps can be worked on in paralel, I would personally like to start with Step 1 soon as I see it as relatively low hanging fruit, with benefits even without Step 2 and 3 finished. Of course, implementing all of steps is a huge amount of work that I will never be able to finish myself. It’s not something that can happen right away either. It’s something we first need to agree on and incorporate into our decision making. If we agree the above is a good direction, I’d need each developer to do a mindset shift to focus first on user experience and ease of use. I’d ask every reviewer to start asking for such things in reviews. I’d need help from UX team to build intuitive wizards. I’d need plugin maintainers to replicate such configuration patterns for their plugins.
So for now, I’d like to hear what you all think. Is this the right path forward?