Grokbase › Groups › Puppet › puppet-users › December 2012
FAQ
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.

Search Discussions

  • Vaidas Jablonskis at Dec 3, 2012 at 12:38 pm ⇧
    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.
  • Peter Brown at Dec 4, 2012 at 12:00 am ⇧

    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+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.
  • Vaidas Jablonskis at Dec 4, 2012 at 11:18 am ⇧
    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.
  • Peter Brown at Dec 5, 2012 at 2:10 am ⇧

    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)?

    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.
  • Vaidas Jablonskis at Dec 5, 2012 at 11:10 am ⇧

    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 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.
  • Peter Brown at Dec 6, 2012 at 2:29 am ⇧
    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 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.
  • Chad Huneycutt at Dec 6, 2012 at 4:08 am ⇧

    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+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Peter Brown at Dec 6, 2012 at 5:13 am ⇧

    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+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.
  • Jcbollinger at Dec 6, 2012 at 2:08 pm ⇧

    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.
  • Peter Brown at Dec 6, 2012 at 11:31 pm ⇧

    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+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.
  • Ryan Cunningham at Dec 7, 2012 at 2:11 am ⇧
    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<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.
  • Peter Brown at Dec 7, 2012 at 3:00 am ⇧

    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<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.
  • Peter Brown at Dec 7, 2012 at 3:40 am ⇧
    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 <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" 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.
  • Llowder at Dec 3, 2012 at 2:20 pm ⇧

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedDec 3, '12 at 3:42a
activeDec 7, '12 at 3:40a
posts15
users6
websitepuppetlabs.com

6 users in discussion

Peter Brown: 8 posts Vaidas Jablonskis: 3 posts Chad Huneycutt: 1 post Jcbollinger: 1 post Ryan Cunningham: 1 post Llowder: 1 post

Content

People

Support

Translate

site design / logo © 2022 Grokbase