It's been a long standing issue that installer users who try to alter
Foreman settings end up surprised when those changes get wiped out
when they upgrade (by running the installer again). Many things can
be set by installer flags, but not all.
Most recently we added the ability to interface directly with Hiera in
/etc/foreman/custom-hiera.yaml
(Foreman :: Manual)
which greatly opens up the configuration to customization.
However, there's still a few limitations with this, particularly if
you need to instantiate a new resource. A good example is wanting to
tune postgresql configuration which uses the postgresql::server::config_entry defined type.
You can get around it this by using the foreman puppet classes
directly and then including a class of your own with the additional
config. But what if you want to use the installer?
Should we deal with these on a case-by-case basis - maybe make
specific postgresql settings accessible in puppet-foreman flags or
take a hash of them in the module?
The other thing I was thinking - and I'm not sure if this is overkill
is giving the user a directory to dump their own custom puppet
modules in, and then using the custom-hiera.yaml feature to include
them.
My thinking was on a profiles module which included, among others,
advanced postgresql options. The clustering that Sean proposed1 is an
example that doesn't belong in one existing module, but is a good thing
to have in the installer.
Another thing I'd want is better control over DNS and DHCP provisioning.
The foreman_proxy::proxy{dns,dhcp} classes are lacking. Properly
exposing dns::zone and dhcp::pool would be similar to exposing
postgresql::server::config_entry.
Personally I also think the puppet-katello module is already some sort
of profile module. It should be refactored to allow composition and work
is in progress for this.
Another item that's been on my wishlist for a long time is converting
the installer to a Puppet environment and make the Foreman host
self-managing.
I was planning on hacking up a proof of concept for both now that the
RCs are out of the door.
ยทยทยท
On Tue, Apr 11, 2017 at 09:50:28AM -0400, Stephen Benjamin wrote:
> It's been a long standing issue that installer users who try to alter
> Foreman settings end up surprised when those changes get wiped out
> when they upgrade (by running the installer again). Many things can
> be set by installer flags, but not all.
>
> Most recently we added the ability to interface directly with Hiera in
> /etc/foreman/custom-hiera.yaml
> (https://theforeman.org/manuals/1.14/index.html#advanced-module-configuration)
> which greatly opens up the configuration to customization.
>
> However, there's still a few limitations with this, particularly if
> you need to instantiate a new resource. A good example is wanting to
> tune postgresql configuration which uses the
> `postgresql::server::config_entry` defined type.
>
> You can get around it this by using the foreman puppet classes
> directly and then including a class of your own with the additional
> config. But what if you want to use the installer?
>
> Should we deal with these on a case-by-case basis - maybe make
> specific postgresql settings accessible in puppet-foreman flags or
> take a hash of them in the module?
>
> The other thing I was thinking - and I'm not sure if this is overkill
> - is giving the user a directory to dump their own custom puppet
> modules in, and then using the custom-hiera.yaml feature to include
> them.
>
> Thoughts/ideas would be much appreciated.
