Foreman installer layout and components digest

Support
1

Hello,

I’m opening a new topic in case it may help somebody new to Foreman and Puppet like I was (and still am, though less and less ;-)).

After more detailed researched, and after my original post (Foreman in multi interface setup experience digest) here’s what I understood (correct me if I’m wrong) about the foreman layout (as installed on CentOS following the manual) :

There are 3 main components :

  • foreman-installer
  • foreman
  • foreman-proxy

each having resources in /etc/ and /usr/share/ directories

/etc/foreman-installer and /usr/share/foreman-installer
/etc/foreman and /usr/share/foreman
/etc/foreman-proxy and /usr/share/foreman-proxy

I. foreman-installer

/sbin/foreman-installer : ruby, kafofy generated, exec script

Configuration(s)

  • /etc/foreman-installer/ : config dir

  • /etc/foreman-installer/custom-hiera.yaml : custom hiera data-source

  • /etc/foreman-installer/scenario.d/ : kafo scenarii (only one named Foreman in our case)

  • /etc/foreman-installer/scenario.d/foreman.yaml : foreman scenario config file

  • /etc/foreman-installer/scenario.d/last_scenario.yaml -> foreman.yaml : last scenario (foreman in our case since there’s only one)

In config file we find, among other entries :

:mapping: {}
:answer_file: /etc/foreman-installer/scenarios.d/foreman-answers.yaml
:installer_dir: /usr/share/foreman-installer
:module_dirs: /usr/share/foreman-installer/modules
:hiera_config: /usr/share/foreman-installer/config/foreman-hiera.conf
:parser_cache_path: /usr/share/foreman-installer/parser_cache/foreman.yaml
    :order:
    - foreman
    - foreman_proxy
    - puppet

So we can see where are located the different components of the foreman-installer. For instance, the answer file for this single scenario is

/etc/foreman-installer/scenarios.d/foreman-answers.yaml

Puppet modules

/usr/share/foreman-installer/modules/ : modules used by foreman-installer and considered for kafo generated CLI options

Manifests

  • /usr/share/foreman-installer/modules/<module>/manifests/ : Puppet code of <module>

  • /usr/share/foreman-installer/modules/<module>/manifests/init.pp : class <module> (<type> $<param> = $<module>::params::<param>) inherits <module>::params {…} : main class of <module> which inherits params to use its parameters

  • /usr/share/foreman-installer/modules/<module>/manifests/params.pp : class <module>::params holding parameters used in <module> class defined in init.pp. Also where kafo gets it’s default parameters values.

  • /usr/share/foreman-installer/modules/<module>/manifests/<other class>.pp : class or defined type <module>::<otherclass> (…) {…} : other classes or defined types defined in the module which may be instanciated

Templates

/usr/share/foreman-installer/modules/<module>/templates/ : templates dir of <module> module

(Ruby) Types

/usr/share/foreman-installer/modules/<module>/types/ : Ruby types used by <module>

Hiera conf

Puppet automatically looks for parameters in Hiera, so this is preferred to the init.pp / params.pp Puppet pattern.

In hiera data source files, entries look like that :

<module>::<param>: <value>

/usr/share/foreman-installer/config/foreman-hiera.conf : global hiera config file (might be one per module as well)

Interesting values, among others, are :

:hierarchy:
   - custom
   - kafo_answers
   - security
   - tuning
   - "%{::osfamily}"

and

:datadir: /usr/share/foreman-installer/config/foreman.hiera

The custom.yaml data source, which is a symlink to /etc/foreman-installer/custom-hiera.yaml allows to pass additionnal (not defined in params.pp file for instance) parameters (an additional dhcp subnet for instance)

Puppet parser cache

/usr/share/foreman-installer/parser_cache/foreman.yaml : Puppet parser cache (checked against manifests timestamps)

Migrations

I’m not quite sure how this works (I haven’t checked it out yet)

II. Foreman-proxy (Smart Proxies)

  • /etc/foreman-proxy/ : Smart Proxies configuration dir

  • /etc/foreman-proxy/settings.yml : general Smart Proxies settings

  • /etc/foreman-proxy/settings.d/*.yml : per proxy settings

Those files are initially created by the foreman_proxy Puppet module (via the foreman-installer) :

/usr/share/foreman-installer/modules/foreman_proxy

As a matter of fact, in this module, there are Puppet defined types and templates matching those files

UI vs Puppet (foreman-installer)

What’s done in the UI has nothing to do with what’s done with the installer. In particular, creating a subnet via foreman-installer options (i.e. via puppet modules) - possibly augmented with additionnal subnets listed in custom-hiera.yml data sources, has nothing to do with what’s done in the subnet tab in the UI

For instance, here’s how the Puppet code typically flows :

  • foreman_proxy (init.pp) class inherits foreman_proxy::params (params.pp) class and uses its parameters

  • foreman_proxy::service (service.pp) class requires foreman_proxy::config (config.pp) class

  • foreman_proxy::config (config.pp) class conditionnally includes foreman_proxy::proxydhcp class

  • foreman_proxy::proxydhcp (proxydhcp.pp) instanciates classes (dhcp, pool) of the general ::dhcp module

  • foreman_proxy::config class instanciates foreman_proxy::settings::settings_file defined type

  • defined type foreman_proxy::settings::settings_file expands templates of foreman-proxy settings files (i.e. settings.yml and settings.d/*.yml) :

So regarding dhcp, there isn’t 2 modules as the layout might let one think but a general dhcp module and its particular use in the foreman-installer context :

/usr/share/foreman-installer/modules/dhcp/ : module
/usr/share/foreman-installer/modules/foreman_proxy/manifests/proxydhcp.pp : specific use of the module

Questions :

  • At this point, I’m not sure if actions done in the UI car write into setting.yml and settings.d/*.yml file

  • kafo seems to provide a reset parameter option to restore to the (not considering answer file) default value but I don’t know if all defaults can be restored

Thanks

–
TH.

1 Like