----- 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.
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?)
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)
--
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.
