We use a "classifier pattern", using this as a starting point http://nuknad.com/2011/02/11/self-classifying-puppet-nodes/ Basically, we have a few custom facts that tell a node what it is (the facts are set via a small MCollective plugin), and then the facts are consumed at Puppet runtime.
2 gotchas: 1) for hiera standalone, it uses /etc/hiera.yaml for config. For puppet/hiera, it uses /etc/puppet/hiera.yaml (yes, this is in the docs somewhere, but I have the attention span of a gnat) 2) If you change hiera.yaml, you need to restart the Puppet Master service (last time I checked, anyways) On Thu, Mar 7, 2013 at 12: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<http://docs.puppetlabs.com/hiera/1/>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. > > > -- GVoice: 707.410.0371 LinkedIn: http://www.linkedin.com/in/brendanobra -- 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.
