I'm trying to understand the concepts underlying Foreman. In other words,
"how is Foreman meant to be used?"
I've installed Foreman on a VM, played with it for a few hours and browsed
through the documentation. For what Puppet is concerned, it looks like
Foreman expects that you create Puppet classes on the Foreman UI, but you
have to install modules from the command line, directly on the server.
Later, you have to issue a command from to UI to sync the changes in the
file system with the Foreman database.
To me, this seems a bit uncoherent. It's a bit like there is a piece in the
middle not yet covered by the UI (i.e. the installation and/or creation +
modification of modules). It's especially disturbing that you have to
connect with SSH and run commands manually. You could say, this is mainly a
cosmetic issue, a usability concern, but it's really an anti-pattern in
continuous delivery. Servers should be locked down, nobody should be
allowed to make uncontrolled changes. Since none of all the changes are
under version control it's impossible to do rollbacks, and there's probably
not even an audit trail for the changes to the host, neither for the Puppet
configuration nor for changes to Foreman.
The whole situation feels a bit uncomfortable. The Puppet configuration is
an important asset, it's source code that I want to have revisioned,
quality checked (linted), and saved offsite in case the server burns down,
so it can be restored reliably if needed. I could now install Git on the
Foreman host, put /etc/puppetlabs/puppet/code/ under version control, and
deploy changes via a CI server. The problem here is that I have to throw
away any changes (to the Puppet configuration) made by Foreman, otherwise
there will a polluted system, or even a merge conflict.
In other words, Forman is not made with version control in mind, is this
correct? Can anyone confirm this finding?
Can we do something about it? - Think this: If the Foreman host were
actually locked down the only way to introduce changes to the host were by
changing the Puppet configuration that sets up the host itself (which,
fortunately, is already under control of Puppet/Foreman). If the Puppet
configuration on the host could be pushed to a Git repository, and changes
to it be committed and deployed (automatically) back to the host then the
situation would look more promising. The UI to modify the Puppet
configuration would have to be read-only, or it would have to make changes
directly on the main branch of the repository and commit (and push) them
right after any modification.