> > Since reading the reasoning here I've continued to think about this off > and on and still have a hard time with the idea of hard-coding > configuration. It seems like a bit of a paradox within puppet. When > writing modules it is generally accepted to separate any configuration data > from the module code, but when writing profiles go ahead and hard code as > many values as possible. I've been trained to think that separating data > from code is a "Good Thing", so going counter to that makes me question my > own existence.
Just a little more to think on -- separating data from code is a really good thing, but its not universally always a good thing. There are times when putting data in code is the right choice (for instance a small amount of static data required by an application). In Puppet, this choice can also come down to a "pets vs. cattle" situation. I often find myself advising people to put data in a Puppet profile and NOT in Hiera precisely because the data should not change across Hiera hierarchy levels. If I have profiles for a shared service/platform in multiple opertional environments, I don't want unique snowflake versions of it all across the Hiera hierarchy. Putting the data in the profile manifest can ensure it stays the same for any instance of the profile. On Saturday, August 24, 2019 at 12:52:19 AM UTC-4, Chris Southall wrote: > > > Good points and a nice example. In the case of my basic module I'm >> currently using a separate create_resources line for each class parameter. >> Is there a way to iterate over all class parameters using each() so I can >> use a single nested loop to create everything? >> >> You can - add an extra tier to the hash with the first level being the >> resource name and then create a default hash with a key for each type you >> use - but I simply don’t think it scales, especially once you need to merge >> data from multiple layers of hiera. Even the deepest merge will, to my >> knowledge, end up replacing and not augmenting the hash values under each >> key. > > ... > >> A deep merge will merge in the the new key ‘package’, but *replace* the >> ‘user’ key, resulting in rnelson0 and appuser everywhere but only >> localbackups on node ‘somenode’. Because of this, it’s not as flexible as >> you’d think. You can see more detail at >> https://puppet.com/docs/puppet/5.0/hiera_merging.html (can’t find the >> 6.x link but to the best of my knowledge, it works the same). >> > > I thought about the extra tier to the hash approach, but decided against > it due to the merge behavior. A simple merge at the top level provides > good enough flexibility and predictable results. > > It also doesn’t scale because you’re writing YAML not code, as Luke >> suggested earlier. Testing is difficult, and troubleshooting is difficult, >> and ordering is even more difficult. If you want to, say, add a repo and >> make sure it’s managed prior to any packages, you’re gonna have to spell >> out the ordering in your YAML, whereas something like ‘Repo <| tag == >> “class” |> -> Package <| tag == “class” |>’ within a class can set that >> ordering only for the related resources much more easily. >> > > This is more to my original point. I'd just as soon avoid writing code > and define my environment in data, although you do need to define resource > dependencies explicitly this way and testing/troubleshooting is a concern. > I've found troubleshooting to be fairly straight forward to this point, > although the environment is growing and complexity with it. For testing I > generally sacrifice a goat (an expendable system) to see that changes I've > added do what's expected before releasing to the full target audience. > > The last thing I’d point out is that composition is a really good pattern, >> and a one-class-does-it-all is an anti-pattern to that. Doing just what you >> need in a series of single, small classes allows you to easily compose a >> desired state through a role that includes the relevant, and just the >> relevant, classes. Within each profile, you should be able to delineate >> much of the specifics, rather than dynamically determine them at runtime >> via a superclass. >> >> > >> Perhaps a question to ask is, how opinionated are your profiles, and how >> opinionated should they be? IMO, very, and that would probably lower the >> number of resources you need to dynamically define. > > > The profiles we currently use have a significant number of parameters to > customize behavior, so we do have a good amount of data in hiera. This is > what led me to think: "if I'm putting this much in hiera, why not put > everything in hiera?". I couldn't really come up with a good reason not > to go this route, so I started this thread. > > Since reading the reasoning here I've continued to think about this off > and on and still have a hard time with the idea of hard-coding > configuration. It seems like a bit of a paradox within puppet. When > writing modules it is generally accepted to separate any configuration data > from the module code, but when writing profiles go ahead and hard code as > many values as possible. I've been trained to think that separating data > from code is a "Good Thing", so going counter to that makes me question my > own existence. > > For those who may be interested, I've re-visited my module on the forge > and updated it to use proper iteration with abstract types instead of > create_resources() per the previous points made in this thread. My > software comes with no warranty expressed or implied. > -- 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/fa599039-9d4a-4507-945d-acb2361f4e07%40googlegroups.com.
