I don't know of a way to have multiple hierarchies, but if you need central
control of parameters like profile you can use an ENC. At one point I even
experimented with a yaml- based ENC that used my hiera data files to keep
all the information in one place.
On Mar 8, 2013 10:54 AM, "Chad Huneycutt" <chad.huneyc...@gmail.com> wrote:
> 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.
>
>
>
--
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.
