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 <rals...@pobox.com> 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 puppet-users+unsubscr...@googlegroups.com.
> To post to this group, send email to puppet-users@googlegroups.com.
> 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 puppet-users+unsubscr...@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
