On 2 July 2010 09:50, David Schmitt <[email protected]> wrote:
> On 6/30/2010 10:57 AM, Matt wrote:
>>
>> On 29 June 2010 17:22, Luke Kanies<[email protected]> wrote:
>>>
>>> Hi all,
>>>
>>> Given the number of threads on variable scoping recently, it's pretty
>>> clear
>>> we need to change how it works. Markus has a lot of this redone in his
>>> futures branch, and I'm asking him to fully describe what the results
>>> will
>>> be when that's merged, but my guess is that there are different
>>> expectations
>>> for what people want to see.
>>>
>>> So, my question is, what behaviour changes would you like to see in how
>>> variable scoping works? How would you like the edge cases that are
>>> currently hurting you to behave?
>>>
>>
>> I'd like to see the ability to reference and change variables from
>> other classes.
>>
>> class httpd { $monitor::services += 'httpd1' }
>> class nginx { $monitor::services += 'nginx' }
>>
>> And if $monitor::services doesn't exist then it's just created with
>> one of the above rather than having to specify $monitor::services = []
>>
>> Or use the new staging feature for ordering where I could do:
>>
>> stage 1 includes class monitor { $monitor::services = [] }
>> stage 2 includes class httpd, nginx as above
>
> How is $monitor::service used, that this cannot read
>
> class httpd { monitor::service { 'httpd1': } }
> class nginx { monitor::service { 'nginx': } }
>
> ?
$monitor::service is used to monitor all services that are in that
array. So node include monitor, httpd, nginx
class monitor { deploy monitoring for all services in $monitor::service }
Being able to do if $monitor::service includes(httpd) would also be cool.
Matt
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
