Custom Kafo-based puppetmaster installer fails if puppetmaster has a yaml flie in production environment

Support
1

Introduction:

We have created a custom puppetmaster installer using Kafo. The goal of the installer is to allow setting up new puppetmasters easily and to maintain them over time. In general the installer works very well and is “production ready”.

I’m asking this question here as I presume this problem has been solved in Foreman installer already.

Problem:

The installer fails with a cryptic ruby error message iff if a yaml file for the node is present in Hiera under production environment, e.g. /etc/puppetlabs/code/environments/production/data/nodes/puppet.example.org.yaml.

If the yaml file is not present, the installer runs just fine.

In practice this problem occurs when the puppetmaster is put into production and environments have been deployed (e.g. with r10k). This prevents rerunning the installer on a production puppetmaster, e.g. to change some of its settings post-install. It also prevents updating the installer with new features and deploying those features on production puppetmasters.

Expected outcome:

Our custom installer should run fine even if the puppetmaster has a yaml file in Hiera’s production environment.

Other relevant data:

Puppet (version 5) has been installed from latest Puppetlabs packages. Kafo installer source code is here.

2

Some further information. The problem is actually triggered if the node has a classes array in Hiera, for example:

classes:
  - myclass

The classes array does have to be in the node-specific yaml: it can come from anything in the hierarchy, e.g. common.yaml.

3

We confirmed that the official Foreman installer has the same problem.

4

To reproduce to problem two conditions have to be met:

  • Hiera is used as an ENC
  • The default environment (“production”) contains the classes array

Possible fixes in the temporary puppet.conf file created by Kafo:

  • Point it to a randomly named environment
  • Point hiera_config to a(n empty) directory inside the Kafo installer
5

Great to hear someone else is also using Kafo.

Interestingly enough I was working on something related to this. Basically we need to get rid of the global variables and move to scoped variables. I had a WIP commit that does this for most, but it looks like I missed the hiera_include('classes').

We can probably move this to a class parameter so you’re not bound to the classes variable.

No promises because of time constraints, but I’m planning on a major version bump of Kafo that gets rid of all the Puppet 3 compatibility code and fully moves to Puppet 4+. The only thing I can’t get rid of is the RDoc parsing for parameter groups, otherwise I’d also move to pure puppet-strings. If that was possible, we could probably drop kafo_parsers.