merging in-module default data with role-profile parameters

[Luke Bigum]

Hello,

I've come across an issue with how I want to write profiles vs how a module chooses to structure their default data.  As an example, the choria-io/puppet-mcollective module uses hashes of in-module data for each configuration file (which is quite elegant, reduces the amount of templates needed).  My issue with it is how I want to explicitly define some parameters for a profile I'm writing.  If I set a few keys of the 'server_config' hash I end up overwriting the rest of the defaults in the module data, because an explicitly defined class param trumps the entire in-module data hash:

**************************

  class { '::mcollective':

    server        => true,

    client        => true,

    server_config => {

      rpcauditprovider          => 'choria',

      'plugin.rpcaudit.logfile' => '/var/log/puppetlabs/choria-audit.log',

    },

  }

**************************

I've got a solution by calling lookup() to get the original data structure, then doing a hash merge in Puppet code:

**************************

  $default_data = lookup('mcollective::server_config')

  $my_data = {

    rpcauditprovider          => 'choria',

    'plugin.rpcaudit.logfile' => '/var/log/puppetlabs/choria-audit.log',

  }

  class { '::mcollective':

    server        => true,

    client        => true,

    server_config => $default_data + $my_data,

  }

**************************

Would anyone consider that a dumb approach? Are there better ways?

Thanks,

-Luke

[R.I.Pienaar]

I have not really found a elegant solution, and I think the right way is
to stick this stuff in hiera on the mcollective::server_config key
rather than try and set it via the params.

You're not doing anything programatic about this data, so why not put it
in hiera?

[Luke Bigum]

On Friday, 14 July 2017 17:17:03 UTC+1, R.I. Pienaar wrote:

I have not really found a elegant solution, and I think the right way is
to stick this stuff in hiera on the mcollective::server_config key
rather than try and set it via the params.

You're not doing anything programatic about this data, so why not put it
in hiera?

 

The "why" is mostly to do with what I consider to be "data" and what I consider to be "design", influenced a little bit by coding style and the use/abuse of Hiera in our environment.  I can boil it down to three main points:

Design in one place - if I'm writing Profiles that use tech/component modules, I prefer all the design/business logic in one place (in a profile) rather than have half the params in Puppet code and half of it in Hiera.  Profile parameters that are actually data are in Hiera.

"Staticness" / Attempt to reduce entropy - hard coding component class parameters makes it harder if not impossible for a value to be overridden in Hiera, and thus make machines different / introduce entropy. In a perfect world this probably wouldn't happen, but all too often I find examples of an engineer fixing one specific problem by setting one specific Hiera key for a node, not knowing that they've just made that machine behave differently to it's 19 other sibling machines that are supposed to be exactly the same. Discipline and code review also helps stop this from happening.

Testing - If I care a *very* great deal about a certain parameter's value, I can write this data value in Puppet code and RSpec Unit test / Beaker acceptance test that Profile.  If that value came from Hiera, I'd have to begin testing my Hiera data, and since the top level of my Hierarcy is "Node", doesn't that mean I'd have to run the same test for each of my 20 nodes that are supposed to be the same...?  With the value hardcoded in Puppet, I've got one place to test the value. I get a certain level of assurance that it can't change, and a certain degree of confidence that the machines that profile applies to are "the same".

[R.I.Pienaar]

I see, fair points. In that case you're best bet is the lookup you
describe or just duplicating the settings into your profile and hard
coding it, its not a lot.

Be aware though that next release of that module will manage the entire
config file and purge all things there not in config - over all better
but one more thing to consider when upgrading to the next version for
this approach specifically


--
R.I.Pienaar / www.devco.net / @ripienaar