FAQ
Good day

Im using puppet 2.7.18 and hiera 1.1.0.

I would like to ask.

For some servers I manage I use the following to pull in 'custom classes'.
hiera_include('classes')

And it all works very well.

But Im now have a class that I now need to class via hiera, and pass
arguments too (the argument, really is where the clients DKIM keys reside).

Can I have puppet / hiera call a parametrised class from hieras yaml file.

Thanks
Brent Clark

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Llowder at Apr 16, 2013 at 12:35 pm

    On Tuesday, April 16, 2013 4:19:26 AM UTC-5, Brent wrote:
    Good day

    Im using puppet 2.7.18 and hiera 1.1.0.

    I would like to ask.

    For some servers I manage I use the following to pull in 'custom classes'.
    hiera_include('classes')

    And it all works very well.

    But Im now have a class that I now need to class via hiera, and pass
    arguments too (the argument, really is where the clients DKIM keys
    reside).

    Can I have puppet / hiera call a parametrised class from hieras yaml file.
    In Puppet3, there is databindings, which will do auto-lookups in hiera for
    all class params.

    Only way to get this behaviour in 2.7.x is to setup the params to invoke
    hiera, such as:

    class myklass(
    $param1 = hiera('myklass::param1', 'somedefault'),
    $param2 = hiera('myklass::param2', 'othervalue'),
    ...

    The "myklass::param1" naming setup for the hiera key value is not strictly
    needed, but it is how it will be expected to be in puppet3 for
    databindings, so I would recommend that you use that naming style now, to
    ease upgrades later.


    Thanks
    Brent Clark
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Apr 16, 2013 at 1:04 pm

    On Tuesday, April 16, 2013 7:35:01 AM UTC-5, llowder wrote:

    On Tuesday, April 16, 2013 4:19:26 AM UTC-5, Brent wrote:

    Good day

    Im using puppet 2.7.18 and hiera 1.1.0.

    I would like to ask.

    For some servers I manage I use the following to pull in 'custom
    classes'.
    hiera_include('classes')

    And it all works very well.

    But Im now have a class that I now need to class via hiera, and pass
    arguments too (the argument, really is where the clients DKIM keys
    reside).

    Can I have puppet / hiera call a parametrised class from hieras yaml
    file.
    In Puppet3, there is databindings, which will do auto-lookups in hiera for
    all class params.

    Only way to get this behaviour in 2.7.x is to setup the params to invoke
    hiera, such as:

    class myklass(
    $param1 = hiera('myklass::param1', 'somedefault'),
    $param2 = hiera('myklass::param2', 'othervalue'),
    ...

    The "myklass::param1" naming setup for the hiera key value is not strictly
    needed, but it is how it will be expected to be in puppet3 for
    databindings, so I would recommend that you use that naming style now, to
    ease upgrades later.

    Yes, loading the data via explicit hiera calls is a good solution. As long
    as you're going to rely on that, however, you're not gaining any advantage
    from class parameterization. You can therefore write it this way instead:

    class myklass {
    $param1 = hiera('myklass::param1', 'somedefault')
    $param2 = hiera('myklass::param2', 'othervalue')
    ...
    }

    That is, as an ordinary unparameterized class. I would recommend that to
    you in any case, but especially so in Puppet 2.


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Mohit Chawla at Apr 16, 2013 at 1:50 pm
    HI,

    John, doesn't it have the advantage of a seamless upgrade to puppet 3.0 ?
    Can you elaborate on why its not advantageous to use explicit hiera calls ?

    On Tue, Apr 16, 2013 at 6:34 PM, jcbollinger wrote:


    On Tuesday, April 16, 2013 7:35:01 AM UTC-5, llowder wrote:


    On Tuesday, April 16, 2013 4:19:26 AM UTC-5, Brent wrote:

    Good day

    Im using puppet 2.7.18 and hiera 1.1.0.

    I would like to ask.

    For some servers I manage I use the following to pull in 'custom
    classes'.
    hiera_include('classes')

    And it all works very well.

    But Im now have a class that I now need to class via hiera, and pass
    arguments too (the argument, really is where the clients DKIM keys
    reside).

    Can I have puppet / hiera call a parametrised class from hieras yaml
    file.
    In Puppet3, there is databindings, which will do auto-lookups in hiera
    for all class params.

    Only way to get this behaviour in 2.7.x is to setup the params to invoke
    hiera, such as:

    class myklass(
    $param1 = hiera('myklass::param1', 'somedefault'),
    $param2 = hiera('myklass::param2', 'othervalue'),
    ...

    The "myklass::param1" naming setup for the hiera key value is not
    strictly needed, but it is how it will be expected to be in puppet3 for
    databindings, so I would recommend that you use that naming style now, to
    ease upgrades later.

    Yes, loading the data via explicit hiera calls is a good solution. As
    long as you're going to rely on that, however, you're not gaining any
    advantage from class parameterization. You can therefore write it this way
    instead:

    class myklass {
    $param1 = hiera('myklass::param1', 'somedefault')
    $param2 = hiera('myklass::param2', 'othervalue')
    ...
    }

    That is, as an ordinary unparameterized class. I would recommend that to
    you in any case, but especially so in Puppet 2.


    John

    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jcbollinger at Apr 17, 2013 at 1:33 pm

    On Tuesday, April 16, 2013 8:50:08 AM UTC-5, alcy wrote:
    HI,

    John, doesn't it have the advantage of a seamless upgrade to puppet 3.0 ?
    Can you elaborate on why its not advantageous to use explicit hiera calls ?
    Read again. I did not recommend against explicit hiera calls; indeed, my
    suggestion relies on them. Rather, I recommended against class
    parameterization. Either solution will work without modification in both
    Puppet 2 (assuming hiera is installed) and Puppet 3, though the
    parameterized version might cause Puppet 3 to perform a redundant lookup
    for each parameter.

    I have written extensively in the past on the shortcomings of Puppet
    parameterized classes. To be fair, the problem isn't really with
    parameterized classes themselves, but rather with parameterized-style class
    declarations (i.e. class { 'foo': param1 => 'bar' }; do not confuse those
    with class *definitions*). You should not use them in Puppet 2 or in
    Puppet 3 because they are subject to parse-order issues, and they can
    mislead about what you can and can't do with classes (for example, attempts
    to override class parameters are silently ineffective).

    My point is that if you are going to rely exclusively on hiera to bind data
    to your classes, then there is little advantage to using class parameter
    formalism at all. You can just make the erstwhile parameters be ordinary
    class variables, initialized via hiera. This reduces the conceptual weight
    of your classes and enforces their intended mode of use.


    John

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Mohit Chawla at Apr 17, 2013 at 2:12 pm
    Hi,

    Understood, thanks for clearing that up ! Will check the archive for more
    discussions on the mentioned parse-order issues.

    On Wed, Apr 17, 2013 at 7:03 PM, jcbollinger wrote:


    On Tuesday, April 16, 2013 8:50:08 AM UTC-5, alcy wrote:

    HI,

    John, doesn't it have the advantage of a seamless upgrade to puppet 3.0 ?
    Can you elaborate on why its not advantageous to use explicit hiera calls ?
    Read again. I did not recommend against explicit hiera calls; indeed, my
    suggestion relies on them. Rather, I recommended against class
    parameterization. Either solution will work without modification in both
    Puppet 2 (assuming hiera is installed) and Puppet 3, though the
    parameterized version might cause Puppet 3 to perform a redundant lookup
    for each parameter.

    I have written extensively in the past on the shortcomings of Puppet
    parameterized classes. To be fair, the problem isn't really with
    parameterized classes themselves, but rather with parameterized-style class
    declarations (i.e. class { 'foo': param1 => 'bar' }; do not confuse those
    with class *definitions*). You should not use them in Puppet 2 or in
    Puppet 3 because they are subject to parse-order issues, and they can
    mislead about what you can and can't do with classes (for example, attempts
    to override class parameters are silently ineffective).

    My point is that if you are going to rely exclusively on hiera to bind
    data to your classes, then there is little advantage to using class
    parameter formalism at all. You can just make the erstwhile parameters be
    ordinary class variables, initialized via hiera. This reduces the
    conceptual weight of your classes and enforces their intended mode of use.


    John

    --
    You received this message because you are subscribed to the Google Groups
    "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com.
    To post to this group, send email to puppet-users@googlegroups.com.
    Visit this group at http://groups.google.com/group/puppet-users?hl=en.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedApr 16, '13 at 9:17a
activeApr 17, '13 at 2:12p
posts6
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase