On Apr 19, 2012, at 11:45 AM, R.I.Pienaar wrote:
>
>
> ----- Original Message -----
>> From: "Andrew Parker" <a...@puppetlabs.com>
>> To: puppet-dev@googlegroups.com
>> Sent: Thursday, April 19, 2012 7:16:40 PM
>> Subject: Re: [Puppet-dev] Changes to variable scoping in Telly
>>
>>
>> On Apr 19, 2012, at 9:38 AM, R.I.Pienaar wrote:
>>
>>> ----- Original Message -----
>>>> From: "Andrew Parker" <a...@puppetlabs.com>
>>>> To: puppet-dev@googlegroups.com
>>>> Sent: Thursday, April 19, 2012 5:30:29 PM
>>>> Subject: Re: [Puppet-dev] Changes to variable scoping in Telly
>>>>
>>>> Absolutely. Debugging is always made fiendishly difficult when
>>>> there
>>>> is "action at a distance" stuff going on. Limiting that kind of
>>>> interaction is why globals are frowned upon in most programming.
>>>> Is
>>>> there a lot of use of globals (topscope) other than facts (and enc
>>>> parameters, I guess) in puppet?
>>>>
>>>
>>> Today there is a lot of it going around. The bulk of modules would
>>> be
>>> written with something like:
>>>
>>> class foo::install {
>>> if $foo_version { $version = $foo_version } else { $version =
>>> "present"}
>>>
>>> package{"foo": ensure => $version}
>>> }
>>>
>>> and then people will "configure" these modules either in site.pp
>>> with
>>> globals or in a node with node scope variables.
>>>
>>> node "blah" {
>>> $foo_version = "1.2.3"
>>>
>>> include foo::install
>>> }
>>>
>>> This is very common, it used to be the only real option outside of
>>> using
>>> extlookup and hiera. And there are vast amounts of code out in the
>>> real
>>> world and on the forge built around this pattern.
>>>
>>> worse, you also had:
>>>
>>> class someother {
>>> $foo_version = "1.2.4"
>>>
>>> include foo::install
>>> }
>>>
>>> and so depending on the parse order of the actual include lines the
>>> outcome
>>> might be different in the end, this being at the whim of the
>>> autoloader and
>>> such it was a bit tricksy.
>>>
>>> All of this code either needs big refactors or just doesnt work
>>> with 2.7.
>>>
>>
>> Thanks for these examples, they help on lot in my understanding of
>> common patterns (I hope at some point to go through code on the
>> forge and try to get some more understanding).
>>
>> Since I'm not entirely clear on all the changes from 2.7 to 2.6, what
>> changed to make these things stop working in 2.7? From my
>> understanding of the 2.7 variable lookup system it seems like they
>> should work in 2.7.
>
> My examples isnt showing the particular bug I was thinking about - I
> will need to go dig through IRC logs to find the particulars.
>
> However in the above examples accessing $foo_version would log a deprecation
> warning saying you must use fully qualified variable path. But for node
> variables there is no fully qualified variable path so you're just stuck
> and forced to make peace with a all the warnings since there's no non
> param classes way to fix that. This is less drastic than 'doesnt work' but
> for many its unacceptable either way as no clear way exist to fix this dire
> warning of impending future doom:
>
> warning: Dynamic lookup of $nodevar at /home/rip/test.pp:4 is deprecated.
> Support will be removed in Puppet 2.8. Use a fully-qualified variable name
> (e.g., $classname::variable) or parameterized classes.
>
That warning has been fixed now in 2.7 head (see
http://projects.puppetlabs.com/issues/13312) and I think will be in the
upcoming 2.7 release. The warning should no longer be issued for facts, node
vars, local vars, or var from inherited scope (parent node or class).
Unfortunately it was in there for so long that a lot of damage has been done by
it. :(
> The proposal that started this thread is about that but I believe its the
> wrong way, we need a node scope so people can address node scope variables
> different from top scope variables (what will happen if in a node I set the
> value of a fact if node scope vars become top scope vars?)
>
The question that started this thread was related to the issue that after
dynamic scoping is gone, then node scoped variables are a special case of
lookup, which didn't seem right. I'm hoping to find a solution that simplifies
the rules around variables and still keeps the ability to do all of the things
that people want or need to do. I'm not convinced that adding special cases for
things that look like other variables but aren't is really the best way to go
about simplifying these rules, but I may not understand enough about how things
work at the moment.
Unfortunately the $node::var syntax doesn't really simplify much and adds the
issue that when inheritance happens then what does $node::var refer to? If
$node:: refers to the "current node" then $node::var will keep changing
depending execution order and where things are included, which takes us right
back to dynamic scoping. This also causes a thing that looks like a fully
qualified variable reference, but isn't really. If instead of $node it is
$"nodename":: (e.g. $foo.example.com::) then we have the problem that nodes
don't always have clear names (unless you know the rules for converting a regex
into the name). The hash syntax has all of the same problems (for nodes, but
not for facts).
So I've been trying to understand the uses of node vars (both "correct" and the
ugly hacks that people end up having to do) so that I can get us all on the
same page to make decisions around this.
> And we're suggesting rather than new and wonderful ways to address scopes
> ie $::topscopevar lets just use hashes.
>
> In puppet code we'd have:
>
> $facts["operatingsystem"]
>
> in templates we'd have:
>
> @facts["operatingsystem"]
>
> all nice and simple vs the current situation of $::operatingsystem vs
> scope.lookupvar("::operatingsystem")
>
>>
>>> Until there is wide adoption of param classes or some data system
>>> this
>>> will unfortunately still be the way.
>>>
>>> The proposed hash like syntax will make for much lighter
>>> refactoring apart
>>> from all the other gains expressed in that ticket.
>>>
>>
>> Is the main thing standing in the way of param class adoption the
>> changes that you referenced above that are keeping people moving to
>> 2.7? Or are they in some way inadequate (Jo mentions this in his
>> email)?
>
> I think a capable data system is required to make param classes viable, whats
> wrong with them would be an entirely different thread (of which I think there
> are several in the list archives probably approaching 100s of messages :P)
>
Right, so I think we can just let that issue go for now then :)
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.
