On Thursday, January 31, 2013 8:38:34 AM UTC-6, Schofield wrote: > > I am evaluating Hiera for use in our puppet setup to handle overrides > based on facts. Unfortunately the documentation is slim > http://projects.puppetlabs.com/issues/15295. I am wondering if it is > possible to have multiple hierarchies and be able to choose which > hierarchy to use when calling the hiera functions from a module? > > My line of thought is that operational concerns for configuring the > network/OS/middleware is independent from application environmental > concerns. For example when configuring the OS I care if if the node is in > the DMZ or a specialized firewall'd network segment. I don't care if the > node is going to be used for dev/test/qa/production release path of the > applications. The opposite is true when installing applications. I don't > care about the network since it should already be setup and the OS services > should already just work. I do care if I am in dev/test/qa/production so I > can configure the application properly for that environment. So I would > like to keep the overrides for network/OS/middleware separate from the > application level overrides. >
If you call hiera like $somevalue = hiera(key, default, source) (not sure that is the best name for the 3rd argument) it will, for that call only, override the hierarchy and inject 'source' at the top of the hierarchy. -- 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.
