Hiera + parametrised classes

[Andrey Kozichev]

Hi! 

Couldn't find the answer in the documentation.

Is it possible to source data from Hiera directly into parametrised classes?

To explain:

I have class mcollective(type,middleware_hosts,securityprovider ....)

Can I define all arguments for this class in Hiera and fetch them all in one Hiera call and then use to declare the class?

Similar what is done with create_resources for defined type but for Class?

Just seems waste to me doing individually:

$type = hiera('mcollective::type')

$middleware_hosts = hiera('mcollective::middleware_hosts')

and then in the class declaration:

class { '::mcollective':

      type => $type

      middleware_hosts =>  $middleware_hosts 

Andrey

[Felix Frank]

Hi,

you didn't look hard enough ;-)

http://docs.puppetlabs.com/hiera/1/puppet.html#automatic-parameter-lookup

HTH,
Felix

[Andrey Kozichev]

dahhh, tried to invent a bicycle,

thanks :)

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/52C6D281.6000007%40alumni.tu-berlin.de.
For more options, visit https://groups.google.com/groups/opt_out.

[Fabrice Bacchella]

I defined a custom ruby function called create_type

Then if in my hiera, I define :

localclasses:

   - class1:

         arg1: value

         arg2: value

  - class2:

         arg1: value

         arg2: value

- class3

A simple call to :

$localclasses = hiera_array("localclasses", [])

create_type("class",   $localclasses) will do the trick.

I use hiera_array to merge many hiera files.

It allows to have very readable hiera files to my taste.

I wrote create_type to have a ressource creation that was not too picky about the way it's called.

You need to put create_type.rb in <modules>/lib/puppet/parser/functions

[Andrey Kozichev]

Thanks, interesting.

Do you use this instead of hiera_include + automatic lookups?

Andrey

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0C0BCC51-CB2A-4E74-AA7A-B027B5FC1DB2%40spamcop.net.

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CACzr%3DFf9kEP7nzX8D72Kw2Uj_J%3DTgyMO5jkckuYz60qDJE%2BB2A%40mail.gmail.com.

[Fabrice Bacchella]

Le 3 janv. 2014 à 17:56, Andrey Kozichev <akoz...@gmail.com> a écrit :

Thanks, interesting.

Do you use this instead of hiera_include + automatic lookups?

yes because 

1/ I didn't knew this when I wrote it

2/ It still prefer this way, I think it's more readable and easier to use once the code is written.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CACzr%3DFc0Y0dZgFfWAJZyn-nLnSBp4F-%2BOnR%2BvNQJp3%3DP%2BF5AMQ%40mail.gmail.com.

[Felix Frank]

Hi,

I can see how it's tempting to structure the data more strongly and save
quite some typing in the process.

But keep in mind that this makes it harder (if not impossible), to
easily override single arguments in higher hierarchy layers.

By sticking to flat key-value pairs for automatic binding, you gain
tighter granularity in the data hierarchy.

But again - depending on your typical use cases, this is an interesting
approach. Nice work!

Cheers,
Felix

[Fabrice Bacchella]

Le 4 janv. 2014 à 00:56, Felix Frank <Felix...@Alumni.TU-Berlin.de> a écrit :

> Hi,
>
> I can see how it's tempting to structure the data more strongly and save
> quite some typing in the process.
>
> But keep in mind that this makes it harder (if not impossible), to
> easily override single arguments in higher hierarchy layers.

My purpose is not to save typing (a very low priority objective for me), but having hiera files describe as cleanly as possible the configuration of a node.

For configuration overide, I use some specific key in my hiera hierarchy that describe some commons settings.

For example, and for ssh, it's not configured in localclasses but in a ssh key that is read using hiera, not hiera array.

So I have in common.yaml :
ssh: ssh::simple

in <domain>.yaml
ssh:
ssh::simple:
accessgroup: users

and I can, in <fqdn>.yaml:
ssh:
ssh::strict:
fromhost: "someserver"

I have some common-case for that like ssh, ntp, networkconfig, puppetconfig, authentication, resolvers...

>
> By sticking to flat key-value pairs for automatic binding, you gain
> tighter granularity in the data hierarchy.
>
> But again - depending on your typical use cases, this is an interesting
> approach. Nice work!
>
> Cheers,
> Felix
>
> On 01/03/2014 05:23 PM, Fabrice Bacchella wrote:
>> localclasses:
>> - class1:
>> arg1: value
>> arg2: value
>> - class2:
>> arg1: value
>> arg2: value
>> - class3
>

> --
> 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...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/52C74E14.8020902%40Alumni.TU-Berlin.de.