Yeah, I'd file a bug against that. There may be other considerations,
but unless there's a really good reason for the current behavior I
would expect it to throw an error.
On Tue, Dec 27, 2011 at 1:24 PM, Trevor Vaughan <tvaug...@onyxpoint.com> wrote:
> In that case, it should probably just fail instead of working (and
> yes, it works).
>
> Trevor
>
> On Tue, Dec 27, 2011 at 4:01 PM, Aaron Grewell <aaron.grew...@gmail.com>
> wrote:
>> If you were actually passing the variable, yes. But you're not, you're
>> expecting to reach into a non-class (essentially a grab-bag of resources)
>> and extract data as though it were a class. It isn't and AFAIK you can't.
>> You'll have to put the data in an actual class and address it from there.
>>
>> On Dec 27, 2011 11:21 AM, "Trevor Vaughan" <tvaug...@onyxpoint.com> wrote:
>>>
>>> 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.
>>>
>> --
>> 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.
>
--
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.
