I agree with everything Luke said, but would also like to point out 2 other techniques that are useful:
1) create_resources() is a bit of a kludge left over from puppet 3. Starting in puppet 4 (and 3’s future parser), iteration was added. Instead of create_resources($some_hash), you would say $some_hash.each |$title, $options| {} and create each resource inside the block. You can still use hiera to get the hash as an automatic parameter lookup on the class, but the creation of resources is a bit more explicit. 2) you also get the chance to define defaults, which means users don’t necessarily have to provide everything! Create a $defaults hash and assign it plus the defined overrides as (say for a user) user {$title: * => $defaults + $options}. This merges the options and defaults and applies the resulting hash as the parameters and values for the resource. You can keep your hiera tidier by creating sane defaults and only specifying the overrides in hiera. Have a new default? Modify the code once and all the resources in hiera benefit from it, unless they explicitly override it. A practical example of this might be creating local users on nodes without access to a central auth mechanism, maybe in staging. In your code you create some defaults: $defaults = { ensure => present, password_max_age => 90, shell => ‘/bin/fish’, } Your hiera might look like: profile::linux::local_users: rnelson0: password: ‘hash1’ groups: - wheel password_max_age: 180 root: password: “hash2” password_max_age: 9999 lbigum: ensure: absent In your code, you iterate over the class parameter local_users and combine your defaults with the specific options: $local_users.each |$title, $options| { user { $title: * => defaults + $options, } } Now my user is created, root’s password is changed and set to basically never expire, and Luke’s account is deleted if it exists. This is a good way to combine the power of hiera with the predictability of puppet DSL, maintain unit and acceptance tests, and make it easy for your less familiar puppet admins to manage resources without having to know every single attribute required or even available in order to use them without going too far down the road of recreating a particular well known CM system. It’s always a bit of a balancing act, but I find this is a comfortable boundary for me and one that my teammates understand. There a lot more power to iteration that can be found in the puppet documentation and particularly this article by RI that I still reference frequently https://www.devco.net/archives/2015/12/16/iterating-in-puppet.php Hope that helps. -- 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/db93faba-3059-48f7-a09a-277463713336%40googlegroups.com.