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 [email protected]. 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.
