On Tuesday, September 6, 2016 at 6:03:33 AM UTC-5, Berkeley wrote:
>
> I'm doing a refactor of my puppet code with the profiles+roles design
> pattern. I'm encountering what should be a simple problem, but I'm having
> trouble finding an answer.
>
> With roles/profiles, you instantiate classes using 'include' and fetch the
> parameter values from hiera.
>
That's not a given. I think choice of data binding approach is largely
perpendicular to use of roles & profiles.
> Then, for each node, you specify one role, which in turn includes all the
> relevant classes. Right now I have a hiera hierarchy that references the
> node's OS, environment and host name. However, I also want to provide
> different data based on the role of a node. For example, a webserver and
> an email server might run postfix; the webserver uses it to email the admin
> when something goes wrong, but the email server uses it for much more.
> However, I still don't want to instantiate the parameters of the postfix
> class explicitly from any role or profile to avoid resource conflicts.
>
This is fine if the requirement of every class that wants Postfix is simply
that Postfix must be installed. But suppose two profiles want conflicting
Postfix configurations -- then you *want* Puppet to notice the conflict.
Puppet class / resource conflicts are not a misfeature simply to be avoided
or worked around at any cost; they are an intentional feature serving to
help ensure internal consistency of your configurations. The biggest
problem with them is that they can cast too broad a net.
> So, I would like to write hiera data that applies to a particular role
> (or even a particular profile), like in the following hierarchy below, but
> I have no idea how to do this:
>
> :hierarchy:
> - "fqdn/%{clientcert}"
> - "env/%{environment}"
> - "roles/%{role}"
> - "os/%{osfamily}
> - common
>
>
>
And what prevents you from doing exactly that? $role does not need to be a
fact for that to work -- it can be an ordinary top-scope variable or a
node-scope variable, too. And there are other alternatives
<https://docs.puppet.com/hiera/3.2/variables.html>, too.
John
--
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/45c65764-abbb-4d99-b088-12d24d6954ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
