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
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
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".
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.