Puppet users - Apr 2013 - Puppet / hiera call a parametrised class from hieras yaml file?

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.

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.

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.

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
<John.Bollinger@stjude.org>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.

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.

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
<John.Bollinger@stjude.org>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.