On Sep 16, 2010, at 9:48 PM, Nigel Kersten wrote: > On Thu, Sep 16, 2010 at 6:36 PM, Luke Kanies <[email protected]> wrote: >> On Sep 16, 2010, at 4:03 PM, Nigel Kersten wrote: >> >>> On Thu, Sep 16, 2010 at 12:49 PM, Jeff McCune <[email protected]> wrote: >>>> On Thu, Sep 16, 2010 at 3:36 PM, Luke Kanies <[email protected]> wrote: >>>>> On Sep 16, 2010, at 12:45 PM, Paul Berry wrote: >>>>> >>>>> I'm trying to get a better understanding of how variable scoping is >>>>> intended to work in Puppet. Based on my reading of the code (and some >>>>> experiments), here's the behaviors that I think are intended: >>>>> 1. Variables defined at toplevel can be seen inside classes. For example: >>>>> $var = "value" >>>>> class foo { notify { $var: } } >>>>> include foo >>>>> >>>>> This is a good idea and should stay, short and long term. >>>> >>>> Agreed. >>>> >>>> Also, please keep in mind this entire discussion applies to resource >>>> defaults as well. Whatever behavior we implement for variables should >>>> also be implemented for resource defaults. >>> >>> So the plan is that the only place you can reliably set global >>> resource defaults is directly in your site.pp or in an *import* from >>> site.pp ? >> >> It's more of a hope than a plan at this point, but really, every variable is >> functionally global, in that you can refer to it from anywhere else using >> the scoping syntax. > > Sure, but this model doesn't hold for resource defaults :)
True dat. Sorry, I somehow missed that specified resource defaults. How do you use them now? And if you can provide a bit of depth, I'd appreciate it - that is, how deep the class structures go, whether classes set defaults for orthogonal classes (e.g., security for web), and especially whether you have orthogonal, non-global defaults (e.g., defaults that apply non-globally but to more than one portion of your class heirarchy). I've got some ideas for how this might work, including adding a kind of 'add defaults from class A to my class' behaviour, but they're very nebulous. >>> and thus not inside a class that may include all your other classes? >>> (we have a module 'base' that does all the logic for which other >>> classes should be included) >> >> This can be pretty easily done using fully qualified variables, but it's >> even better done using extlookup or equivalent. > > I disagree pretty strongly that extlookup is better for this specific > purpose, even acknowledging how fully qualified variables let you > achieve this under the proposed model, and that separating data from > models is generally awesome. I'd like to hear more about this. -- The most incomprehensible thing about the world is that it is at all comprehensible. --Albert Einstein --------------------------------------------------------------------- Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199 -- You received this message because you are subscribed to the Google Groups "Puppet Developers" 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-dev?hl=en.
