hiera default values for a variable

[Peter Brown]

Hi everyone,

I currently have a giant file with default variables I use in a lot of my modules and I override those at the node level if I need to.

I thought I would give porting that data into a hiera setup.

I worked out how to specify my data sources and started to make a go at moving some of my variables in the default data file.

I thought heira would be smart and set a variable to undef if it couldn't find it but that doesn't seem to be the case. (unless I missed something in the rather sparse documentation)

Is there a way of telling it to do this?

I was also trying to work out how I automagically get my parametized classed to pull in vars from hiera. (The docs on that don't tell me much either.)

Can anyone tall me how that works? Or do I have to use the hiera functions which isn't automagical in my book.

My current variables are set with a default value in my main file and then I override those at the node level if I need to (so kind of the same way hiera does it anyway)

So given all of that I can't see any reason to switch to using heira because my current setup works as-is (my variable file is getting pretty huge anyway but that isn't going to change with heira if it won't set a var to undef).

What are the benefits or using an external source for variables instead of sticking them in my node definitions (which seems like it would be faster because it doesn't have to use an external source)?

Thanks in advance.

Pete.

[Vaidas Jablonskis]

Hi Pete,

It depends on what version of puppet you use. If you use 3.x, then it has hiera built-in. So it's very simple to write classes which are compatible with v2.7 or v3.x versions.

I normally write something like this:

class foo(

  $parameter = undef,

) {...}

What that means is that puppet will automatically call hiera('foo::parameter') and tries to find a value for $parameter in the hierarchy if it cannot find it, then the value of $parameter will be equal to undef.

[llowder]

On Sunday, December 2, 2012 9:42:08 PM UTC-6, Pete wrote:

Hi everyone,

I currently have a giant file with default variables I use in a lot of my modules and I override those at the node level if I need to.

I thought I would give porting that data into a hiera setup.

I worked out how to specify my data sources and started to make a go at moving some of my variables in the default data file.

I thought heira would be smart and set a variable to undef if it couldn't find it but that doesn't seem to be the case. (unless I missed something in the rather sparse documentation)

Is there a way of telling it to do this?

I was also trying to work out how I automagically get my parametized classed to pull in vars from hiera. (The docs on that don't tell me much either.)

Can anyone tall me how that works? Or do I have to use the hiera functions which isn't automagical in my book.

If you are using puppet 3, then if you do:

class foo ( $bar = bat ) { ... }

puppet will look in hiera for a key named foo::bar if no param is supplied. If it does not find it, then it will use "bat" for the default.
 

My current variables are set with a default value in my main file and then I override those at the node level if I need to (so kind of the same way hiera does it anyway)

So given all of that I can't see any reason to switch to using heira because my current setup works as-is (my variable file is getting pretty huge anyway but that isn't going to change with heira if it won't set a var to undef).

What are the benefits or using an external source for variables instead of sticking them in my node definitions (which seems like it would be faster because it doesn't have to use an external source)?

Separating code from data makes it easier to share / reuse your modules, and can make it possible for "less trustworthy" people to be involved in the editing / creation of nodes
 

Thanks in advance.

Pete.

[Peter Brown]

On 3 December 2012 22:38, Vaidas Jablonskis <jablo...@gmail.com> wrote:

Hi Pete,

It depends on what version of puppet you use. If you use 3.x, then it has hiera built-in. So it's very simple to write classes which are compatible with v2.7 or v3.x versions.

I am testing on 3.

I normally write something like this:

class foo(

  $parameter = undef,

) {...}

Ah nice.

That's pretty logical.

I didn't think of doing that.

What that means is that puppet will automatically call hiera('foo::parameter') and tries to find a value for $parameter in the hierarchy if it cannot find it, then the value of $parameter will be equal to undef.

Ah I wasn't aware I could define vars like that in Hiera.

Is it as simple putting this in one of my data files?

foo::parameter: value

Pete

On Monday, 3 December 2012 03:42:08 UTC, Pete wrote:

Hi everyone,

I currently have a giant file with default variables I use in a lot of my modules and I override those at the node level if I need to.

I thought I would give porting that data into a hiera setup.

I worked out how to specify my data sources and started to make a go at moving some of my variables in the default data file.

I thought heira would be smart and set a variable to undef if it couldn't find it but that doesn't seem to be the case. (unless I missed something in the rather sparse documentation)

Is there a way of telling it to do this?

I was also trying to work out how I automagically get my parametized classed to pull in vars from hiera. (The docs on that don't tell me much either.)

Can anyone tall me how that works? Or do I have to use the hiera functions which isn't automagical in my book.

My current variables are set with a default value in my main file and then I override those at the node level if I need to (so kind of the same way hiera does it anyway)

So given all of that I can't see any reason to switch to using heira because my current setup works as-is (my variable file is getting pretty huge anyway but that isn't going to change with heira if it won't set a var to undef).

What are the benefits or using an external source for variables instead of sticking them in my node definitions (which seems like it would be faster because it doesn't have to use an external source)?

Thanks in advance.

Pete.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/PreiZnQjKIcJ.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Vaidas Jablonskis]

Yes, it is that simple.

The other way of doing (some people prefer this way actually) is to put your variables inside the actual class (not as parameters of the class), for example:

class foo {

  $my_parameter       = hiera('foo::my_parameter', 'default_value')

  $another_parameter = hiera('foo::another_parameter', 'some default value')

  <...>

}

As you can see I didn't use any class parameters, I just put my variable inside the class and used hiera() funciton to fetch the values from hiera data. There are couple of things to understand here:

1. syntax of hiera() is: hiera('parameter_to_look_for', 'default_value_if_not_found')

2. the "parameter_to_look_for" can be anything you like, but the best practice is to keep it consistent, so for example you have a class 'foo' and a variable 'myvar' inside the class, then you should have it as 'foo::myvar' in hiera data files.

Hope this helps.

--

  Vaidas

[Peter Brown]

On 4 December 2012 21:17, Vaidas Jablonskis <jablo...@gmail.com> wrote:

Yes, it is that simple.

I gave it a go just after I sent my email and it works like a charm.

The other way of doing (some people prefer this way actually) is to put your variables inside the actual class (not as parameters of the class), for example:

class foo {

  $my_parameter       = hiera('foo::my_parameter', 'default_value')

  $another_parameter = hiera('foo::another_parameter', 'some default value')

  <...>

}

I was doing it that way but I wasn't aware I could set a default in the hiera call.

That's a pretty handy trick.

As you can see I didn't use any class parameters, I just put my variable inside the class and used hiera() funciton to fetch the values from hiera data. There are couple of things to understand here:

1. syntax of hiera() is: hiera('parameter_to_look_for', 'default_value_if_not_found')

2. the "parameter_to_look_for" can be anything you like, but the best practice is to keep it consistent, so for example you have a class 'foo' and a variable 'myvar' inside the class, then you should have it as 'foo::myvar' in hiera data files.

Ah very cool.

That works just as well as the other way.

I am leaning towards puppet parameter vars in my name::params class because it makes it a bit more portable and will work for those not using hiera yet.

Hope this helps.

Indeed it does.

Thanks for the explanation.

(I would have looked up the docs but they don't seem to exist yet) 

Now I have a nice portable way of setting variables and can rewrite all my classes to actually be portable and will me so  much happier releasing them.

One last question.

I use a node level variable to specify the location of a node.

I use this for setting variables specific to that location like different puppet master ip and nagios ip for the office and such.

I want to use that variable in hiera for the same purpose.

I have this in my hiera.yaml file.

---

:hierachy:

  - %{::clientcert}

  - %{::environment}

  - %{location}

  - virtual_%{::is_virtual}

  - common

:backends: yaml

:yaml:

  :datadir: /etc/puppet/hieradata

it gets data from the common.yaml file but is seems to not get anything from any of the other files.

it's definitely using the datadir because thats where the common.yaml file is as well as the rest of the data files.

Am I missing something?

Pete.

To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/ygahW1cKSLoJ.

[Vaidas Jablonskis]

When you specify variables in hiera.yaml configuration file, then they are facts, not actual Puppet variables. So in this case you have it wrong.

Instead of %{::environment}, use %{environment}, because a fact is always going to be a top scope variable.

[Peter Brown]

That doesn't seem to work either...

I tried putting in another entry called extra (no var just the name) and it didn't get used either.

So it's like it's not using anything that isn't called common.yaml

So my guess is it's not the variables it's something else.

Anyone got any ideas?

Or some docs I can dredge through?

 

To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/dni9mA0j2nwJ.

[Chad Huneycutt]

hiera generates great traces if you enable it. I *think* you enable
debug on the master to turn it on, but there might be something else
you have to do. If all else fails, the code is actually pretty
straight-forward...


--
Chad M. Huneycutt

[Peter Brown]

Do you mean using the --debug flag on a puppet agent run?

I tried that and it didn't tell me anything useful.

I also switched to getting the vars with a hiera('class::variable') call and all that told me was

Error: Could not retrieve catalog from remote server: Error 400 on SERVER: Could not find data item nrpe::params::nagios_ips in any Hiera data file and no default supplied at /usr/local/puppet/environments/development/modules/nrpe/manifests/params.pp:10 on node test.example.com

It doesn't tell me which hiera data files it it searching either which doesn't help at all.

If I move the variable into my common.yaml file it works perfectly.

I don't have the time to dredge through ruby code to find out whats going on.

I still haven't learnt ruby so it would take me longer to work it out.

 

--
Chad M. Huneycutt

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.

[jcbollinger]

On Tuesday, December 4, 2012 8:10:00 PM UTC-6, Pete wrote:

One last question.

I use a node level variable to specify the location of a node.

I use this for setting variables specific to that location like different puppet master ip and nagios ip for the office and such.

I want to use that variable in hiera for the same purpose.

I have this in my hiera.yaml file.

---

:hierachy:

  - %{::clientcert}

  - %{::environment}

  - %{location}

  - virtual_%{::is_virtual}

  - common

:backends: yaml

:yaml:

  :datadir: /etc/puppet/hieradata

it gets data from the common.yaml file but is seems to not get anything from any of the other files.

it's definitely using the datadir because thats where the common.yaml file is as well as the rest of the data files.

Am I missing something?

You are missing that node variables are not globals, and in fact don't even have qualified names.  I strongly suspect that that is why Hiera is not seeing them.

There are several potential workarounds, among them:

• set the needed variable(s) at top-level, based on some sort of conditional
• push all the contents of your node blocks into classes, so that the variables in question become class variables
• instead of creating a separate hierarchy level with a data file for each value of (say) $environment,use a hash of hashes in the level below, with the $environment values as the outer hash keys

Cheers,

John

[Peter Brown]

On Dec 7, 2012 12:08 AM, "jcbollinger" <John.Bo...@stjude.org> wrote:
>
>
>
> On Tuesday, December 4, 2012 8:10:00 PM UTC-6, Pete wrote:
>>
>>
>> One last question.
>> I use a node level variable to specify the location of a node.
>> I use this for setting variables specific to that location like different puppet master ip and nagios ip for the office and such.
>> I want to use that variable in hiera for the same purpose.
>> I have this in my hiera.yaml file.
>>
>> ---
>> :hierachy:
>>   - %{::clientcert}
>>   - %{::environment}
>>   - %{location}
>>   - virtual_%{::is_virtual}
>>   - common
>> :backends: yaml
>> :yaml:
>>   :datadir: /etc/puppet/hieradata
>>
>> it gets data from the common.yaml file but is seems to not get anything from any of the other files.
>> it's definitely using the datadir because thats where the common.yaml file is as well as the rest of the data files.
>> Am I missing something?
>>
>
> You are missing that node variables are not globals, and in fact don't even have qualified names.  I strongly suspect that that is why Hiera is not seeing them.

That explains a why location isn't seen.

I discovered later that hiera didn't seem to be using the facts either...

Do I need to  do something else to allow hiera to see facts?
I am assuming if I can use facts I will work out how to set location as a fact and just use it that way.

As an aside, are ENC variables global?
I have been tempted to use my freeipa server as an ENC using ldap.

I have also been tempted to have a go at writing an ldap backend for hiera but that's another story...

>
> There are several potential workarounds, among them:
> set the needed variable(s) at top-level, based on some sort of conditional

I was under the impression that node level variables were top level variables but I am guessing I am wrong. Time to find some docs I guess. :)

> push all the contents of your node blocks into classes, so that the variables in question become class variables

I am going to assume from that class variables are global because they have qualified names?

> instead of creating a separate hierarchy level with a data file for each value of (say) $environment,use a hash of hashes in the level below, with the $environment values as the outer hash keys
>
> Cheers,
>
> John
>

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/1Ajo2OXHPC4J.

[Ryan Cunningham]

I'm actually having this exact same problem. In my hiera.yaml file I had a hierarchy including two facts and then some strings derived from facter facts.

When I run puppet agent --test the hiera vars in files named for the node's $fqdn, etc. aren't found, but if I puppet apply specifying my site.pp manifest the variables contained in yaml files like $fqdn.yaml are found and applied properly. I've gone as far as testing this with masters running 3.0 and 2.7 but haven't seen any difference. For the sake of clarity, the agent is being run on the master.

I've tried several permutations of specifying a hierarchy including quoting "%{fqdn}",  using no quotes, using the syntax for a top-level variable ${::fqdn}, etc. Each time running hiera from the CLI works as expected but the master can't be coerced to behave as expected.

A bit of pastebin
puppet apply (which works): http://pastebin.com/E5iBtt2t
puppet agent --test (doesn't work): http://pastebin.com/GsA81Eyx

[Peter Brown]

On 7 December 2012 12:11, Ryan Cunningham <ryan.cunni...@gmail.com> wrote:

I'm actually having this exact same problem. In my hiera.yaml file I had a hierarchy including two facts and then some strings derived from facter facts.

Nice to know I am not completely insane. 

When I run puppet agent --test the hiera vars in files named for the node's $fqdn, etc. aren't found, but if I puppet apply specifying my site.pp manifest the variables contained in yaml files like $fqdn.yaml are found and applied properly. I've gone as far as testing this with masters running 3.0 and 2.7 but haven't seen any difference. For the sake of clarity, the agent is being run on the master.

I've tried several permutations of specifying a hierarchy including quoting "%{fqdn}",  using no quotes, using the syntax for a top-level variable ${::fqdn}, etc. Each time running hiera from the CLI works as expected but the master can't be coerced to behave as expected.

A bit of pastebin
puppet apply (which works): http://pastebin.com/E5iBtt2t
puppet agent --test (doesn't work): http://pastebin.com/GsA81Eyx

I didn't try using apply but it does look very similar to my problem.

To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/Gjgrw66TRWkJ.

[Peter Brown]

I worked out my problem.

I spelt hierarchy wrong in my hiera.yaml file...