On Oct 9, 2010, at 11:10 AM, Nigel Kersten wrote:
> On Fri, Oct 8, 2010 at 12:29 PM, Luke Kanies <[email protected]> wrote:
>> On Oct 8, 2010, at 10:53 AM, Paul Berry wrote:
>>
>> Nick and I had a discussion about variable scoping yesterday, and we've come
>> up with a plan to get rid of the confusing aspects of variable scoping and
>> resource defaults in the long term, without putting an undue short term
>> burden on users to rework all their manifests. The plan is based around the
>> idea of getting rid of dynamic scoping in the long run, but giving users a
>> grace period during which dynamic scoping still works, so that they can
>> gradually transition their manifests to using parameterized classes instead
>> of dynamic scoping:
>> 1. Fix tickets 4534, 4778, and 4427. These are the tickets that are
>> preventing people from being able to use parameterized classes effectively
>> now. If possible, fix them in the 2.6.x branch so that the fixes will be
>> released in 2.6.3 and people can start using parameterized classes ASAP.
>> 2. Add a warning to 2.7 that lets people know if when their manifests are
>> relying on dynamic scoping (and hence will break once we switch to lexical
>> scoping). This will give users a chance to transition their manifests
>> gradually over to using parameterized classes where they used to use lexical
>> scoping. It also gives us all time to figure out whether there are any
>> other things we were using dynamic scoping for that can't be easily
>> accomplished using parameterized classes.
>>
>> Markus is definitely right about this - there's a serious risk of
>> log-spamming, and we've gotten big complaints about it in this kind of area
>> in the past.
>>
>> 3. Add an option to 2.7 that lets users switch from dynamic to lexical
>> scoping once they have taken care of all their warnings.
>> 4. In 2.8, assuming we haven't discovered any showstopping reasons to keep
>> dynamic scoping, eliminate the option so that Puppet always uses lexical
>> scoping.
>>
>> Overall seems like a good plan. My only concern is that we'd have to work
>> *really* hard on documentation and communication, and:
>> The big concern about switching to lexical scoping was resource defaults,
>> wasn't it? I think we determined in the end that the defaults just need to
>> be global for most cases anyway, but it's at least something to think about.
>> It might require that we support an 'extend'-like concept, where you can
>> pull defaults (and maybe variables) from one class into another:
>> class mydefaults {
>> File { owner => root }
>> }
>> class mystuff {
>> extend mydefaults
>> }
>> This might make it so we don't need dynamic scoping for defaults. But I
>> might be wrong about Nigel's concerns.
>
> I've thought about this over the last day or so, and this really does
> seem to solve the major use cases.
>
> We can set global resource defaults for ... well defaults.
> We can set local resource defaults within classes for readability.
> We can mixin/extend specific defaults via your proposal.
>
> Just so I'm perfectly clear on how this will work with inheritance...
> What will happen here with File["foo"] under the proposed model?
>
>
> class nkotb {
> File { owner => "root",}
> }
>
> class nsync inherits nkotb {
> file { "foo":
> ...
> }
> }
I actually don't know how the lexical scoping will affect scoping and
inheritance. I assume that File["foo"] would acquire owner => root; Paul?
--
Sabbagh's Second Law:
The biggest problem with communication is the illusion that it
has occurred.
---------------------------------------------------------------------
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.
