Dynamically assign files to hiera hierarchy

[Vincent Miszczak]

Hi,

I'd like to add things dynamically to :hierarchy: when I use hiera.

I'd like to be able to do the following :

in site.pp:

hiera_roles()

hiera_roles() would search in hiera for something like :

mynode.yaml:

roles:

 - roles/appserver

 - roles/databaseserver

and I could have :

roles/appserver.yaml:

classes:

 - appserver

roles/databaseserver.yaml:

classes:

 - databaseserver

So my node is not limited to one role, but to any number of roles I decide. You know, sometime you have nodes acting as appservers or databaseservers and sometimes they do both.

Interpolation tokens in hiera.yaml could have been nice but arrays are not properly expanded in context of hiera. 

I've been looking at the code and this should be pretty straightforward to do so but I really don't get how to write Ruby code. This looks over complicated regarding other language I know such as Python/Java.

I just want a custom function hiera_roles() append to the hierarchy array used by Puppet.

Could someone help with writing this custom function ?

Regards,

Vincent

[Vincent Miszczak]

I finally did it my self.

For sure I hate Ruby.

This custom function will add values from arbitrary keys (must be arrays) at the beginning of "hierarchy"

For my example, I have just included hiera_hook("roles") in site.pp to achieve to behavior I described previously.

module Puppet::Parser::Functions

      newfunction(:hiera_hook) do |*args|

                require 'puppet/indirector/data_binding/hiera'

                require 'hiera'

                require 'hiera/scope'

                require 'puppet'

                key, default, override = HieraPuppet.parse_args(args)

                value=HieraPuppet.lookup(key, default, self, override, :priority)

                hierarchy=Puppet::DataBinding::Hiera.hiera().config[:hierarchy]

                value.each do |val|

                        if not hierarchy.include?(val)

                                hierarchy.insert(0,val)

                        end

                end

      end

end

[Felix Frank]

On 05/02/2014 06:43 PM, Vincent Miszczak wrote:
> For my example, I have just included hiera_hook("roles") in site.pp to
> achieve to behavior I described previously.

Uhuh.

How is this used? Does it actually affect subsequent hiera() calls?

[Vincent Miszczak]

Hi,

Well I did this in a lab with one node.

I used like this :

site.pp:

hiera_hook("roles")

hiera_include("classes")

so my :hierearchy: looked like:

:hierarchy:

 - roles/appserver

 - roles/databaseserver

 - ...

 - common

I suppose the is not enough because subsequent calls will have the hooks registered.

Basically what I want it to be able to have a dynamic hierarchy for each node, for managing groups.

If I use a single role for a node(can be achieved by hiera("role") and %{role}), I have to write 3 roles : app,database,appanddatabase and put classes in them. Then, when I change the settings for database, I have to write the changes in every role somethinganddatabase => error prone.

If I use a wrapper class for each role that encapsulate the settings, when I change settings, I'm writting Puppet code while I want to do this with hiera (not the same guys behind).

Well, I still have to think about it.

Any help is welcome.

[Felix Frank]

On 05/02/2014 09:32 PM, Vincent Miszczak wrote:
> If I use a single role for a node(can be achieved by hiera("role") and
> %{role}), I have to write 3 roles : app,database,appanddatabase and put
> classes in them. Then, when I change the settings for database, I have
> to write the changes in every role somethinganddatabase => error prone.
> If I use a wrapper class for each role that encapsulate the settings,
> when I change settings, I'm writting Puppet code while I want to do this
> with hiera (not the same guys behind).

Hmm, I don't have first hand experience with the pattern, but I believe
you fail to include profiles in your model.

The intent is to have a profile for whatever a node might need to do, in
your example, there might be an appserver profile and a database
profile. (In reality, those are probably devided into an apache profile,
php profile, java profile, mysql profile, oracle profile etc.)

Now the three roles you sketched will include profiles like

app: appserver
database: database
appanddatabase: appserver, database

Since it's the profiles that do all the work, there is no code
duplication to worry about.

Hope that makes sense,
Felix

[William Leese]

For more dynamic hiera hierarchy behaviors, take a look here and add your vote / any relevant links: https://tickets.puppetlabs.com/browse/HI-257