Puppet users - Jan 2013 - Multiple hierarchies with Hiera

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.

-- 
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+unsubscribe@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.

I''ve followed this pattern:
http://nuknad.com/2011/02/11/self-classifying-puppet-nodes/

To accomplish basically the same thing. The structure of the hierarchy is
static, but the values are are supplied are based on facts. So far, so good
with this in my world.


On Thu, Jan 31, 2013 at 6:38 AM, Schofield <dbschofield@gmail.com> 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.
>
> --
> 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+unsubscribe@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.
>
>
>


-- 
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 puppet-users+unsubscribe@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.

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+unsubscribe@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.

Depending on what you are trying to do, using facts in your datadir
can achieve a similar purpose:

:yaml:
  :datadir: /etc/puppet/environments/%{environment}/data

So you in essence have a different hierarchy per environment.

On Thu, Jan 31, 2013 at 12:43 PM, llowder <llowderiv@gmail.com>
wrote:
>
>
> 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+unsubscribe@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+unsubscribe@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.

>
>
>
> 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.
>
This is what I was after.  Thank you.

-- 
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+unsubscribe@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.

>
> :yaml: 
>   :datadir: /etc/puppet/environments/%{environment}/data 
>
> So you in essence have a different hierarchy per environment. 
>
I really need a hierarchy per module instead of a site/environment 
hierarchy.   Looks like R.I.Pienaar is working on this.  
https://github.com/puppetlabs/puppet/pull/1217  Until this gets merged are 
there any tricks to emulate this behavior?




-- 
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+unsubscribe@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.

I totally cheated to achieve module-local data as well as site-local data.

I copied the yaml.rb hiera backend and renamed it siteyaml.rb, then
made a few modifications in the .rb file to reflect the name change.

The result is that I can add an additional back-end with a second datadir.

:yaml:
        :datadir:
/etc/puppet/environments/%{environment}/modules/%{module_name}/hieradata

:siteyaml:
        :datadir: /etc/puppet/environments/%{environment}/hieradata

Ugly, ugly, ugly.  I am pretty sure I got the idea from Luke Bignum,
based on this discussion and bug:

https://groups.google.com/d/topic/puppet-users/Gj32AXNgJ0w/discussion
http://projects.puppetlabs.com/issues/13954

That probably doesn''t help, but it is how I do it.

On Wed, Feb 6, 2013 at 8:53 AM, Schofield <dbschofield@gmail.com>
wrote:
>> :yaml:
>>   :datadir: /etc/puppet/environments/%{environment}/data
>>
>> So you in essence have a different hierarchy per environment.
>
>
> I really need a hierarchy per module instead of a site/environment
> hierarchy.   Looks like R.I.Pienaar is working on this.
> https://github.com/puppetlabs/puppet/pull/1217  Until this gets merged are
> there any tricks to emulate this behavior?
>
>
>
>
> --
> 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+unsubscribe@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+unsubscribe@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.