>
> 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.
>
So you discourage use of create_resources() is favor of each(). I can get
on board with that.
> 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.
>
In fairness, create_resources() also lets you set defaults.
> 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.
>
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?
> 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
>
Thanks for sharing!
--
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/4daec92c-a88c-4994-83cd-3677b7d375ca%40googlegroups.com.
