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 <[email protected]> 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" <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> > 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 >> >> [email protected] >> >> >> >> -- 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 [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. >> >> >> > >> > -- >> > 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. >> > >> >> >> >> -- >> Trevor Vaughan >> Vice President, Onyx Point, Inc >> (410) 541-6699 >> [email protected] >> >> -- 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 [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. >> > -- > 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. -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 [email protected] -- 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 [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.
