>
> 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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/4daec92c-a88c-4994-83cd-3677b7d375ca%40googlegroups.com.
