There are actually pretty good reasons for doing it if you have a
fully modular setup.
For example:
Web Server module define -> Firewall code define -> ERB using higher
level variables.
There's no reason to stuff everything into a big data store when you
can easily pass it down. *But* if you try to use the top level
variable in the second define call ERB, then you've got issues.
I feel that this needs to be either forbidden (break the compile) or
allowed. But we'd need to know how to allow it.
Trevor
On Tue, Dec 27, 2011 at 11:40 AM, Aaron Grewell <aaron.grew...@gmail.com> wrote:
> It's an interesting question, but I wouldn't want to structure my
> modules that way. There are two methods of getting data into a define
> that are guaranteed to work: passing variables and file retrieval
> (extlookup/hiera). Especially given the changes being made to scoping
> anything else is fraught with peril.
>
> On Mon, Dec 26, 2011 at 5:56 AM, Trevor Vaughan <tvaug...@onyxpoint.com>
> wrote:
>> I just ran into an interesting scenario where I didn't know how to
>> scope my variables and I'd just like to share for the crowd.
>>
>> Suppose you have two modules 'foo' and 'bar'. You also have two
>> defines, 'foo::do_stuff' and 'bar::more_stuff'.
>>
>> define foo::do_stuff (
>> $var1 = 'a',
>> $var2 = 'b'
>> ) {
>> bar::more_stuff { 'test': }
>> }
>>
>> define bar::more_stuff (
>> $optional_var = 'ignore'
>> ) {
>> file { '/tmp/test':
>> content => template('bar/random.erb')
>> }
>>
>> +++ random.erb +++
>>
>> var1 = <%= var1 %>
>> var2 = <%= var2 %>
>>
>> So, here, puppet complains about the scope of var1 and var2 but what
>> should the correct scope be? foo::do_stuff::var1, etc...? But how does
>> that work with multiple define calls to foo::do_stuff?
>>
>> This, of course, can be avoided by putting the template under
>> foo/templates and forcing the passage of content to bar::more_stuff
>> but I'm not quite sure *why* this isn't supposed to work and what to
>> do about it with the notice that 2.8 will force the scoping of all
>> variables.
>>
>> Thanks,
>>
>> Trevor
>>
>> --
>> Trevor Vaughan
>> Vice President, Onyx Point, Inc
>> (410) 541-6699
>> tvaug...@onyxpoint.com
>>
>> -- This account not approved for unencrypted proprietary information --
>>
>> --
>> 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+unsubscr...@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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
