Re: [Puppet Users] Re: hiera default values for a variable
On 3 December 2012 22:38, Vaidas Jablonskis 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-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: hiera default values for a variable
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
On Tuesday, 4 December 2012 00:00:21 UTC, Pete wrote:
>
> On 3 December 2012 22:38, Vaidas Jablonskis
> > 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.
>>
>
>
--
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/-/ygahW1cKSLoJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: hiera default values for a variable
On 4 December 2012 21:17, Vaidas Jablonskis 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.
> --
> Vaidas
>
> On Tuesday, 4 December 2012 00:00:21 UTC, Pete wrote:
>>
>> On 3 December 2012 22:38, Vaidas Jablonskis 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)?
Re: [Puppet Users] Re: hiera default values for a variable
On Wednesday, 5 December 2012 02:10:00 UTC, Pete wrote:
>
> On 4 December 2012 21:17, Vaidas Jablonskis
> > 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?
>
> 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.
>
> Pete.
>
>
>> --
>> Vaidas
>>
>> On Tuesday, 4 December 2012 00:00:21 UTC, Pete wrote:
>>>
>>> On 3 December 2012 22:38, Vaidas Jablonskis 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
Re: [Puppet Users] Re: hiera default values for a variable
On 5 December 2012 21:10, Vaidas Jablonskis wrote:
>
>
> On Wednesday, 5 December 2012 02:10:00 UTC, Pete wrote:
>
>> On 4 December 2012 21:17, Vaidas Jablonskis 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?
>>
>> 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.
>
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?
>
>> Pete.
>>
>>
>>> --
>>> Vaidas
>>>
>>> On Tuesday, 4 December 2012 00:00:21 UTC, Pete wrote:
On 3 December 2012 22:38, Vaidas Jablonskis 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 spa
Re: [Puppet Users] Re: hiera default values for a variable
On Wed, Dec 5, 2012 at 9:29 PM, Peter Brown wrote:
> On 5 December 2012 21:10, Vaidas Jablonskis wrote:
>> On Wednesday, 5 December 2012 02:10:00 UTC, Pete wrote:
>>> On 4 December 2012 21:17, Vaidas Jablonskis 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?
>>>
>> 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.
>
>
> 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?
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
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: hiera default values for a variable
On 6 December 2012 14:08, Chad Huneycutt wrote:
> On Wed, Dec 5, 2012 at 9:29 PM, Peter Brown wrote:
> > On 5 December 2012 21:10, Vaidas Jablonskis
> wrote:
> >> On Wednesday, 5 December 2012 02:10:00 UTC, Pete wrote:
> >>> On 4 December 2012 21:17, Vaidas Jablonskis
> 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?
> >>>
> >> 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.
> >
> >
> > 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?
>
>
> 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...
>
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.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: hiera default values for a variable
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
--
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.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: hiera default values for a variable
On Dec 7, 2012 12:08 AM, "jcbollinger" 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.
>
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: hiera default values for a variable
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
On Thursday, 6 December 2012 18:31:09 UTC-5, Pete wrote:
>
> On Dec 7, 2012 12:08 AM, "jcbollinger" >
> 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.
> >
> > 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.
>
--
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/-/Gjgrw66TRWkJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: hiera default values for a variable
On 7 December 2012 12:11, Ryan Cunningham
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.
On Thursday, 6 December 2012 18:31:09 UTC-5, Pete wrote:
>>
>> On Dec 7, 2012 12:08 AM, "jcbollinger" 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
>> .
>> >
>> > 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
>> .
>>
>> --
> 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/-/Gjgrw66TRWkJ.
>
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group,
Re: [Puppet Users] Re: hiera default values for a variable
I worked out my problem.
I spelt hierarchy wrong in my hiera.yaml file...
On 7 December 2012 13:00, Peter Brown wrote:
> On 7 December 2012 12:11, Ryan Cunningham > 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.
>
> On Thursday, 6 December 2012 18:31:09 UTC-5, Pete wrote:
>>>
>>> On Dec 7, 2012 12:08 AM, "jcbollinger" 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
>>> .
>>> >
>>> > 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
>>> .
>>>
>>> --
>> 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/-/Gjgrw66TRWkJ.
>>
>> To post to this group, send email to puppet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> puppet-users+unsubscr...@googlegroups.com.
>> For more options, visit this group a
