Puppet users - Dec 2012 - hiera default values for a variable

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 post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.


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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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.
>
-- 
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/-/0Jf0oeKriKEJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 3 December 2012 22:38, Vaidas Jablonskis <jablonskis@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-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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
<jablo...@gmail.com<javascript:>
> > 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<javascript:>
>> .
>> To unsubscribe from this group, send email to 
>> puppet-users...@googlegroups.com <javascript:>.
>> 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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 4 December 2012 21:17, Vaidas Jablonskis <jablonskis@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.

> --
>   Vaidas
>
> On Tuesday, 4 December 2012 00:00:21 UTC, Pete wrote:
>>
>> 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<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<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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wednesday, 5 December 2012 02:10:00 UTC, Pete wrote:
>
> On 4 December 2012 21:17, Vaidas Jablonskis
<jablo...@gmail.com<javascript:>
> > 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
<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<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<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...@googlegroups.com<javascript:>
>> .
>> To unsubscribe from this group, send email to 
>> puppet-users...@googlegroups.com <javascript:>.
>> 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/-/dni9mA0j2nwJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 5 December 2012 21:10, Vaidas Jablonskis <jablonskis@gmail.com> wrote:
>
>
> On Wednesday, 5 December 2012 02:10:00 UTC, Pete wrote:
>
>> 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?
>>
>> 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
<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/*
>>>>>
*ms**g/puppet-users/-/**PreiZnQjKIcJ<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<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<https://groups.google.com/d/msg/puppet-users/-/ygahW1cKSLoJ>
>>> .
>>>
>>> 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<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/-/dni9mA0j2nwJ.
>
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, Dec 5, 2012 at 9:29 PM, Peter Brown <rendhalver@gmail.com>
wrote:
> On 5 December 2012 21:10, Vaidas Jablonskis <jablonskis@gmail.com>
wrote:
>> On Wednesday, 5 December 2012 02:10:00 UTC, Pete wrote:
>>> On 4 December 2012 21:17, Vaidas Jablonskis
<jablo...@gmail.com> 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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 6 December 2012 14:08, Chad Huneycutt <chad.huneycutt@gmail.com> wrote:
> On Wed, Dec 5, 2012 at 9:29 PM, Peter Brown <rendhalver@gmail.com>
wrote:
> > On 5 December 2012 21:10, Vaidas Jablonskis
<jablonskis@gmail.com>
> wrote:
> >> On Wednesday, 5 December 2012 02:10:00 UTC, Pete wrote:
> >>> On 4 December 2012 21:17, Vaidas Jablonskis
<jablo...@gmail.com>
> 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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Dec 7, 2012 12:08 AM, "jcbollinger"
<John.Bollinger@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.
>
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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"
<John.Bo...@stjude.org<javascript:>>
> 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<javascript:>
> .
> > To unsubscribe from this group, send email to 
> puppet-users...@googlegroups.com <javascript:>.
> > 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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 7 December 2012 12:11, Ryan Cunningham
<ryan.cunningham.xyzzy@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.

On Thursday, 6 December 2012 18:31:09 UTC-5, Pete wrote:
>>
>> 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<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<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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I worked out my problem.
I spelt hierarchy wrong in my hiera.yaml file...


On 7 December 2012 13:00, Peter Brown <rendhalver@gmail.com> wrote:
> On 7 December 2012 12:11, Ryan Cunningham
<ryan.cunningham.xyzzy@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.
>
> On Thursday, 6 December 2012 18:31:09 UTC-5, Pete wrote:
>>>
>>> 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<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<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+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.