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".

-- 
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/bb3b78bf-fe5c-4340-a875-0ec15186ddb8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to