Hi there, 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. Peter -- You received this message because you are subscribed to the Google Groups "Foreman users" group. To unsubscribe from this group and stop receiving emails from it, send an email to foreman-users+unsubscr...@googlegroups.com. To post to this group, send email to foreman-users@googlegroups.com. Visit this group at https://groups.google.com/group/foreman-users. For more options, visit https://groups.google.com/d/optout.
