Puppet users - Dec 2011 - Collecting resources and class defaults.

Hi,

This is very possibly by design so I am checking that is by design and if so
there is a consistant work around.

Any class defaults look to be set when the class is stored , any class
defaults are then
effectively ignored when the resources are collected.

A trivial example that works to demonstrate the case:

A top scope entry in site.pp such that site.pp is evaluated
differently for each host.

File{
    content => $::hostname
}

And then on HostA define a resource

@@file {''/tmp/test'':
        ensure => present,
        tag => ''testtag'',
}

And on HostB collect the resource:
File <<| tag == ''testtag'' |>>

The result is that HostB ends up with the default class definitions from HostA

# cat /tmp/test
HostA

The default is taken from storage host rather than collecting host.
This may well be by design ?

Can I persuade the collection to take the collecting hosts class defaults with
out doing a per variable override
File <<| tag == ''testtag'' |>> { content =>
$::hostname }

which rather defeats the point of having a default in the first place.

I''m working with EPEL''s puppet-2.6.12-1.

Steve.

-- 
Steve Traylen

-- 
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 Dec 1, 3:59 am, Steve Traylen <steve.tray...@cern.ch>
wrote:
> Hi,
>
> This is very possibly by design so I am checking that is by design and if
so
> there is a consistant work around.
>
> Any class defaults look to be set when the class is stored , any class
> defaults are then
> effectively ignored when the resources are collected.

You mean resource property defaults, of course.

> A trivial example that works to demonstrate the case:
>
> A top scope entry in site.pp such that site.pp is evaluated
> differently for each host.
>
> File{
>     content => $::hostname
>
> }
>
> And then on HostA define a resource
>
> @@file {''/tmp/test'':
>         ensure => present,
>         tag => ''testtag'',
>
> }
>
> And on HostB collect the resource:
> File <<| tag == ''testtag'' |>>
>
> The result is that HostB ends up with the default class definitions from
HostA
>
> # cat /tmp/test
> HostA
>
> The default is taken from storage host rather than collecting host.
> This may well be by design ?

Indeed it is, doubly so.  First, the whole point of exported resources
is that the *exporting* node defines all their properties.  Second,
*all* the properties of a resource are exported, even those taking
default values, therefore the collecting node sees no properties
needing default values anyway.

> Can I persuade the collection to take the collecting hosts class defaults
with
> out doing a per variable override
> File <<| tag == ''testtag'' |>> { content =>
$::hostname }
>
> which rather defeats the point of having a default in the first place.

No.  If you give us an example of a real problem you are trying to
solve, however, then perhaps we can offer some better advice.


John

-- 
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 Thu, Dec 1, 2011 at 4:16 PM, jcbollinger <John.Bollinger@stjude.org>
wrote:
>> The default is taken from storage host rather than collecting host.
>> This may well be by design ?
>
> Indeed it is, doubly so.  First, the whole point of exported resources
> is that the *exporting* node defines all their properties.  Second,
> *all* the properties of a resource are exported, even those taking
> default values, therefore the collecting node sees no properties
> needing default values anyway.
>
Thanks for confirming that - it makes sense to me as it stands.
>> Can I persuade the collection to take the collecting hosts class
defaults with
>> out doing a per variable override
>> File <<| tag == ''testtag'' |>> { content
=> $::hostname }
>>
>> which rather defeats the point of having a default in the first place.
>
> No.  If you give us an example of a real problem you are trying to
> solve, however, then perhaps we can offer some better advice.
The real example is really very similar. The site.pp contains

Firewall{
   noop      => $firewallnoop,
   loglevel  => $firewallloglevel
}

with those variables set by the ENC per host, this allows hosts to opt
out of firewall configuration
essentially despite manifests being littered with firewall openings.

The override attribute on collection is fine and the variable can
still be used since that will come from the ENC
on collecter side. My other option is to use the enc variable to case
if the firewalls should even be collected in the first place which
probably makes sense.

Thanks for the comments.

-- 
Steve Traylen

-- 
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.