I didn't. Seems odd but it might work.
Unfortunately, there's not really a way to know what 'name' would be
from the lower level define unless you were sure to call it with the
same name.
If you did that, you could use Foo::Do_stuff[$name]::var1 but I don't
really see another way of doing it.
Probably a bug.
Trevor
On Tue, Dec 27, 2011 at 4:46 PM, Aaron Grewell <aaron.grew...@gmail.com> wrote:
> Hmm, I just thought of this. Normally when referencing an instance of
> a define you would use this syntax (note the caps):
>
> Foo::Do_stuff['name']
>
> Did you try:
> Foo::Do_stuff['name']::var1
>
> On Tue, Dec 27, 2011 at 1:37 PM, Aaron Grewell <aaron.grew...@gmail.com>
> wrote:
>> 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.
>
--
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.
