(it would help a lot if you set your mail client to text only as is the
convention on the list)
----- Original Message -----
> From: "Andrew Parker" <a...@puppetlabs.com>
> To: puppet-dev@googlegroups.com
> Sent: Tuesday, April 17, 2012 5:47:02 PM
> Subject: Re: [Puppet-dev] Changes to variable scoping in Telly
>
> I'm not sure if you are agreeing with me or not and on what. Since we
> might be seeing different elephants in the room, could you spell you
> what it is and what should be done with it?
>
In the past we had:
the fact $operating system
node foo {
$operatingsystem = "AIX"
}
class foo {
$operatingsystem = "RedHat"
}
define bar {
$operatingsystem = "Solaris"
}
and at any time you could be getting the value for any one of these, which
would be used at any given time was a nasty tangle of leaky scopes. This
is way too much for much of the target audience to really understand - but
it allowed for a lot of freedom. It's a newbie trap and constant source of
frustration.
We then started going down the route of saying all this leaky scope stuff
is bad, its magical, its non deterministic, when you read a piece of code
you have no idea what data you are actually looking at. Is it a fact, or
a variable, a node variable a variable in the define scope or in the class
or something else entirely.
The fact that facts can be overridden is complete insanity.
We started fixing this by deprecating the dynamic lookup stuff and leaky
scope things and introducing parameterized classes and started logging
warnings and deprecations whenever any of this magical variable overriding
is happening.
So now we're rapidly approaching a world where these leaky scope problems
are a thing of the past, instead we have clear obvious variable origin, you
can more or less imagine looking at some modern puppet code and *know* where
a variable might come from.
EXCEPT in the case of top scope and node scope variables. They're the glaring
omission in our plan thus far.
We have facts that are facts, facts should be constants they should be immutable
instead they're kind of magical and depending if your remember to do
::operatingsystem
you might not get what you thought you would get. The proposed fix to node
variables is a step backward into this confusing state.
Instead we're suggesting we use the hash capabilities - a recent addition -
to create clear named scopes and types of variables
The hash $facts would be all the facts, they would be immutable and unchanging
The hash $node_facts would be all node scope variables
The hash $master_settings would be puppet master config settings replacing
$settings::foo
and so forth and so on - I dont care for what these are called - but the point
is once you've taken a newbie and explained to him what a fact is wrt to puppet
and when he then come across a piece of code that says:
notify{$facts["operatingsystem"]: }
there's no room for confusion, its clear as day what we're talking about and
we can clearly enforce the immutability of these variables etc.
--
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.
