Hi James,
We are in a similar situation. I think of it slightly
differently, though. We are trying to use the roles/profiles pattern,
and I am having trouble figuring out how to get hiera to use the
profile to do the lookup. So rather than explicitly listing the
values in the hierarchy, I want:
:hierarchy:
- host/%{::fqdn}
- profiles/%{profile}
- common
So not per node, but per profile, but it seems like that is what you
really want anyway?
I could, as Brendan suggests, distribute a fact out to all the nodes,
but I worry about the security of that solution since it puts the node
in control of its configuration.
I have come up with a scheme that will work if I can figure out the
class that included the class that does the hiera lookup, but that is
a bit of a hack and probably not scalable.
Ideally, I would love it it puppet supported a pattern like
roles/profiles directly in the dsl and could expose that to hiera.
- Chad
On Thu, Mar 7, 2013 at 3:11 PM, James Ralston <[email protected]> wrote:
> We have a small and growing Puppet infrastructure we started a few months
> ago: about 30 modules and 40 hosts.
>
> At this point, all of the modules we have written use parameterized classes.
> That way, when we call the module from the host's node.pp file, we can
> override defaults (if necessary).
>
> We knew using parameterized classes wouldn't scale. Now that we've upgraded
> to Puppet 3 on the server and all of our clients, we want to do things the
> Hiera way.
>
> The problem is, we've been unable to find any good documentation on how to
> use hiera and Puppet together.
>
> Yes, we've read the hiera documentation on the puppetlabs web site. That was
> helpful in explaining hiera general concepts, but it doesn't really explain
> how to integrate hiera data lookup with Puppet.
>
> The main thing we're trying to understand is how each host manifest can
> declare its own hiera hierarchy for data lookup. We can't do this with the
> yaml backend, because the yaml backend will apply the same hierarchy to
> EVERY client, because all Puppet clients use the /etc/puppet/hiera.yaml file
> on the puppetmaster. Granted, we can customize the hierarchy on the
> puppetmaster with facter facts, but that doesn't give us enough control.
>
> For example, host foo might want:
>
> :hierarchy:
> - host/%{::fqdn}/config
> - app/external-nameserver/config
> - common/config
>
> But host bar might want:
>
> :hierarchy:
> - host/%{::fqdn}/config
> - app/internal-mailserver/config
> - common/config
>
> That's what we can't figure out how to do with hiera.
>
> Frustratingly, the one section of the hiera documentation on the puppetlabs
> web site that looks like it might explain what we need to know—the "Usage
> with Puppet" section—just says "Coming soon".
>
> There's just no way we're the only site out there using Puppet who needs to
> vary the hiera lookup hierarchy per node. What's the secret to it? How do
> you actually do it?
>
> Thanks,
> James
>
> --
> 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 post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/puppet-users?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
Chad M. Huneycutt
--
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 post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
