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 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.
