----- Original Message -----
> From: "Andrew Parker" <a...@puppetlabs.com>
> To: puppet-dev@googlegroups.com
> Sent: Thursday, April 19, 2012 8:42:33 PM
> Subject: Re: [Puppet-dev] Changes to variable scoping in Telly
>
> I've got a branch of puppet that has dynamic scoping removed.
> Considering the impact that this will have on things and my personal
> uncertainty about whether people will still be able to achieve
> everything they want to with puppet, I'd really like to get people
> to grab it and try it out.
>
> https://github.com/zaphod42/puppet/tree/feature/13970/remove-dynamic-scoping
This Just Works for me, but I've deliberately never had any dynamic lookup
in my code as I've always used extlookup/hiera to avoid this problem so thats
not a surprise, someone else will need to test with more broken manifests :P
So I am guessing the thing that would happen is variables that were previously
filled in would be undef without dynamic scope or what would be the the exact
effects of this?
Do you have sample code showing what worked before and failed after? and how
would that failure/change in behaviour manifest?
>
> 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.
> >
> > 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.
> >
>
> --
> 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.
