> 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. For example:
#default.yaml
---
Profile::base::all_resources:
user:
rnelson0: {}
appuser: {}
#clientcert/somenode.yaml
---
Profile::base::all_resources:
user:
localbackups: {}
package:
tree: {}
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).
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.
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.
--
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/a99ca4b4-6e81-4559-8f59-329d322993e4%40googlegroups.com.
