On 21/05/17 22:21, Peter Bittner wrote:
> 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
You don't "have" to do this, you should probably deploy the Puppet
environment and modules from source control using r10k or
librarian-puppet. Installing modules by hand is fine for an example
(e.g. in documentation), but you should have a better way to do it in
practice.
> Later, you have to issue a command from to UI to sync the
> changes in the file system with the Foreman database.
You can also run `foreman-rake puppet:import:puppet_classes[batch]`
after deploying the environment change(s).
> 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.
Changes to hosts and their assigned Puppet classes made through the
Foreman UI should have audit entries created under Monitor > Audits, but
there's no rollback mechanism.
As you say, changes to the modules in the deployed Puppet environments
can, and probably should, be version controlled. This isn't done within
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.
Foreman doesn't modify Puppet environments, manifests or any other
on-disk data in your Puppet environment, it only imports from them. This
sounds quite reasonable and sensible.
The data in Foreman is mostly associations between its hosts and the
modules and classes in the environment ("classification"). You can also
set top-level class parameters.
> 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.
You can manage classification and host-level data in either Foreman (or
another ENC) or within the Puppet environment through node definitions
or Puppet data lookup (Hiera) etc.
If you want to version control host/node classification, then you'd be
much better off doing that inside your Puppet manifests and data files,
then deploying it alongside the modules in your Puppet environment from
source control. Foreman would just be used for reporting and provisioning.
If you want to use Foreman's web UI to manage hosts rather than source
control, then do so, and you can still deploy modules in the Puppet
environment from source control.
--
Dominic Cleal
[email protected]
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.
