We’ve been using Foreman for years, but don’t keep a close eye on Foreman developments.
It’s our belief that Puppet manifests make it easier to apply smaller, incremental changes compared to the Foreman Installer.
Also, it’s not always clear what files are managed by the Foreman Installer. Since we only run the Foreman Installer occasionally, we may inadvertently revert a critical configuration away a config file without realizing it. It’s harder to do this with a Puppet manifest.
Or, to approach this another way: If I install via foreman-installer the first time can I somehow dump the config into a Puppet manifest which I could maintain with the theforeman/foreman module?
Then I could just maintain everything from a manifest moving forward.
The installer uses the same puppet modules, but there are also some hooks that live outside of puppet modules, that might be useful. I think this is even more important when you install katello. But in general, you can use puppet modules standalone as well. There’s no easy way to get installer’s values and convert them to puppet parameters automatically, but installer has answer file, where it stores all such values. So you could take this file and convert it manually.
If you run this before you run installer for the first time, you’ll get default recommended values. After first run, it also contain values that were used as defaults for your system.
Running foreman-installer was super easy. I suppose what I’ll do now is to try and copy the correct modules to my production environment, write a manifest, and then run in no-op mode to see if I accidentally changed anything that is managed by Foreman Installer.
Hi, @Marek_Hulan hoping you could shed a little more light. I’m trying to translate the values from foreman-answers.yaml into some Puppet manifests.
If I understand the foreman-answers.yaml format correctly, it contains a number of top-level directives with names like foreman:, :foreman::cli:, foreman_proxy:, puppet:, followed by a section applying to that top-level directive. For my own server, I wanted to stick with the defaults as much as possible, and thus my own file doesn’t have that many differences from a default. Here are some example sections from my own file:
Am I correct in assuming that these top level directives, like foreman: and puppet: are referring to Puppet modules such as theforeman/foreman and theforeman/puppet, and the parameters underneith are essentially the same as the Puppet parameters for those modules?
Yes, you got it exactly right. Top level modules are foreman, foreman_proxy and puppet. The key that contains :: instantiate some subclass from one of these modules, handy for plugins or cli setup.
Our installer is indeed effectively a wrapper around puppet modules with some hooks and migrations. These migrations allow us to move parameters when we rename them or change some data when needed.
As the maintainer of the installer and its puppet module I consider this a supported way of deploying Foreman. It’s how I run my personal Foreman instance and I know we have quite a few production users doing the same thing. It does mean you need to keep up with our modules, but we try to make this easier by publishing a CHANGELOG.md for every module. We also keep compatibility with older releases (current - 1 at least) so you can update your modules before updating the entire installation.
Internally Kafo has code to generate a hiera answers file because in the end it’s essentially puppet apply kafo_configure.pp with hiera set up. It’s a pretty straight forward conversion (as you already noticed) and ideally we’d provide some command line utility to convert it for these use cases.
Yes, every setting can be enforced that way. We don’t have an easy parameter available now to just set a hash of them, but you can write it in your own profile class.
