On Mon, Jul 17, 2017, at 11:12, Luke Bigum wrote: > 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".
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 -- 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/1500286624.459792.1043176856.1CA4C9C3%40webmail.messagingengine.com. For more options, visit https://groups.google.com/d/optout.
