Puppet users - May 2007 - Global Variables?

What is the view of having / not having global variables in Puppet?
Facter variables are global in the sense they are defined in every scope
(whereas ''normal'' variables are only available within the
scope they are
defined in).

I could simply add a custom fact for my DoesTheServerNeedASerialConsole
flag to Facter, but I''m not 100% sure I should be having the client
decide this.  It''s something to be declared centrally.

I''d use a variable but it goes out of scope if I use inheritance.  I
want to define something per host (or per group of hosts) that is
available to all low-level classes.

Best regards,
Derek
------------------------------------------------------------------------
For important statutory and regulatory disclosures and more information about
Barclays Capital, please visit our web site at http://www.barcap.com.

Internet communications are not secure and therefore the Barclays Group does not
accept legal responsibility for the contents of this message.  Although the
Barclays Group operates anti-virus programmes, it does not accept responsibility
for any damage whatsoever that is caused by viruses being passed.  Any views or
opinions presented are solely those of the author and do not necessarily
represent those of the Barclays Group.  Replies to this email may be monitored
by the Barclays Group for operational or business reasons.

Barclays Capital is the investment banking division of Barclays Bank PLC, a
company registered in England (number 1026167) with its registered office at 1
Churchill Place, London, E14 5HP. This email may relate to or be sent from other
members of the Barclays Group.
------------------------------------------------------------------------

On May 1, 2007, at 10:20 AM, <Derek.Whayman@barclayscapital.com> wrote:
> What is the view of having / not having global variables in Puppet?
> Facter variables are global in the sense they are defined in every  
> scope
> (whereas ''normal'' variables are only available within the
scope
> they are
> defined in).
In some senses of the word, all variables are global in Puppet, they  
are just sticky to the scope in which they''re defined.  In 0.22.4,  
you can now refer to variables from separate classes (e.g.,  
$os::darwin::dnsserver), which makes all variables even more like  
globals.

All child scopes automatically attempt to resolve undefined variable  
dereferences in their parent scopes, and all scopes have the top- 
level scope as their ultimate parent scope, so Facter variables  
(which are defined in the top-level scope) are thus available to all  
scopes.

However, as you say, these can be overridden by any other scope,  
which means it and its child scopes (if any) will get a different value.

Unfortunately, there''s no way to fix that while remaining somewhat  
declarative.
> I could simply add a custom fact for my  
> DoesTheServerNeedASerialConsole
> flag to Facter, but I''m not 100% sure I should be having the
client
> decide this.  It''s something to be declared centrally.
If it should be defined centrally, use a parser function:

https://reductivelabs.com/trac/puppet/wiki/WritingYourOwnFunctions
> I''d use a variable but it goes out of scope if I use inheritance. 
I
> want to define something per host (or per group of hosts) that is
> available to all low-level classes.
Subclasses should be able to look up variables defined in parent  
classes, although subclasses cannot override parent variables.

  --
  I used to get high on life but lately I''ve built up a resistance.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

Absolutely, I have the variables inheriting from child scopes (must''ve
made a mistake before).  But the problem is that I want something the
other way around, i.e. to set a variable in a child scope and have it
referred up to a parent scope (which doesn''t work by design). 
Actually,
David Schmitt just posted something to this effect - it seems I''d made
a
common mistake.

node mynode0123 inherits basenode {
    $var = "mynode0123_specific"
}

node basenode {
    include myclass # Do general stuff with a few node-specific tweaks
}

myclass doesn''t see $var - it is scoped out of existence.

It''s something of a coincidence that my child scope has a 1:1
relationship with a node.  So a Facter variable is of the global scope
(and thus myclass can see the node-specific settings) - but - crucially
it contains node-specific information - convenient!

I suppose I could define a parser function to imnplement something like
"Declared Global Facts" that can retrieve child-scoped information in
a
parent scope.  But does this make sense given the way Puppet''s config
is
supposed to be architected?  Is Puppet going that way?

The alternatives are
(i)   Pull "myclass" from the "basenode" entries and put it
in all of
the mynode (hostname) node entries - this is what David Schmitt seems to
be doing
(ii)  The above, plus not extending the node hierarchy down to the
individual host level (thus keeping the amount of duplication in the
config files down)

I''m quite keen to hear opinions on this as I''m designing our
Puppet
templates from a blank sheet.

Regards,
Derek
 

-----Original Message-----
From: puppet-users-bounces@madstop.com
[mailto:puppet-users-bounces@madstop.com] On Behalf Of Luke Kanies
Sent: 01 May 2007 18:06
To: Puppet User Discussion
Subject: Re: [Puppet-users] Global Variables?

On May 1, 2007, at 10:20 AM, <Derek.Whayman@barclayscapital.com> wrote:
> What is the view of having / not having global variables in Puppet?
> Facter variables are global in the sense they are defined in every 
> scope (whereas ''normal'' variables are only available
within the scope
> they are defined in).
In some senses of the word, all variables are global in Puppet, they are
just sticky to the scope in which they''re defined.  In 0.22.4, you can
now refer to variables from separate classes (e.g.,
$os::darwin::dnsserver), which makes all variables even more like
globals.

All child scopes automatically attempt to resolve undefined variable
dereferences in their parent scopes, and all scopes have the top- level
scope as their ultimate parent scope, so Facter variables (which are
defined in the top-level scope) are thus available to all scopes.

However, as you say, these can be overridden by any other scope, which
means it and its child scopes (if any) will get a different value.

Unfortunately, there''s no way to fix that while remaining somewhat
declarative.
> I could simply add a custom fact for my 
> DoesTheServerNeedASerialConsole flag to Facter, but I''m not 100%
sure
> I should be having the client decide this.  It''s something to be 
> declared centrally.
If it should be defined centrally, use a parser function:

https://reductivelabs.com/trac/puppet/wiki/WritingYourOwnFunctions
> I''d use a variable but it goes out of scope if I use inheritance. 
I
> want to define something per host (or per group of hosts) that is 
> available to all low-level classes.
Subclasses should be able to look up variables defined in parent
classes, although subclasses cannot override parent variables.

  --
  I used to get high on life but lately I''ve built up a resistance.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com


_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
------------------------------------------------------------------------
For important statutory and regulatory disclosures and more information about
Barclays Capital, please visit our web site at http://www.barcap.com.

Internet communications are not secure and therefore the Barclays Group does not
accept legal responsibility for the contents of this message.  Although the
Barclays Group operates anti-virus programmes, it does not accept responsibility
for any damage whatsoever that is caused by viruses being passed.  Any views or
opinions presented are solely those of the author and do not necessarily
represent those of the Barclays Group.  Replies to this email may be monitored
by the Barclays Group for operational or business reasons.

Barclays Capital is the investment banking division of Barclays Bank PLC, a
company registered in England (number 1026167) with its registered office at 1
Churchill Place, London, E14 5HP. This email may relate to or be sent from other
members of the Barclays Group.
------------------------------------------------------------------------

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 02 May 2007, Derek.Whayman@barclayscapital.com
wrote:
> Absolutely, I have the variables inheriting from child scopes
(must''ve
> made a mistake before).  But the problem is that I want something the
> other way around, i.e. to set a variable in a child scope and have it
> referred up to a parent scope (which doesn''t work by design). 
Actually,
> David Schmitt just posted something to this effect - it seems I''d
made a
> common mistake.
>
> node mynode0123 inherits basenode {
>     $var = "mynode0123_specific"
> }
>
> node basenode {
>     include myclass # Do general stuff with a few node-specific tweaks
> }
>
> myclass doesn''t see $var - it is scoped out of existence.
>
> It''s something of a coincidence that my child scope has a 1:1
> relationship with a node.  So a Facter variable is of the global scope
> (and thus myclass can see the node-specific settings) - but - crucially
> it contains node-specific information - convenient!
Only classes/nodes using overrides need to inherit things. If you are working 
with config variables then you can just include the parent class instead of 
inheriting it.


Regards, David
- -- 
- - hallo... wie gehts heute?
- - *hust* gut *rotz* *keuch*
- - gott sei dank kommunizieren wir über ein septisches medium ;)
 -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFGOFLn/Pp1N6Uzh0URAp7HAKCGStp9m1RrlX5sULtl+CmVJ9P0iwCfWUkQ
qJ51y8246IP5LI+QsqjfDEI=GORN
-----END PGP SIGNATURE-----

--On Wednesday, May 02, 2007 08:54:56 +0100 
Derek.Whayman@barclayscapital.com wrote:
> node mynode0123 inherits basenode {
>     $var = "mynode0123_specific"
> }
>
> node basenode {
>     include myclass # Do general stuff with a few node-specific tweaks
> }
>
> myclass doesn''t see $var - it is scoped out of existence.
I don''t see why myclass *should* see that variable.  I''m a
strong proponent
of Puppet being limited in the sense that it encourages more disciplined 
approach to configuration instead of "you can do this a million ways."
I
think Puppet was written with that in mind.

One of the reasons setting global variables was problematic is what happens 
if you tried to set $var in two places that both get parsed for the node 
you are evaluating for?  Which takes precident?  With overrides, you can 
atleast have some sense of relationship so as to make that determination, 
but something of the above would really not make "object oriented"
sense,
IMHO.

So, the question that comes to mind is, "What are you trying to
achieve?"
I have found that often when I have wanted "new features" in Puppet,
it was
because I wanted to force Puppet to think of things *my* way instead of me 
thinking of things in *Puppet''s* way.

> I suppose I could define a parser function to imnplement something like
> "Declared Global Facts" that can retrieve child-scoped
information in a
> parent scope.  But does this make sense given the way Puppet''s
config is
> supposed to be architected?  Is Puppet going that way?
I would hope not.  That would be problematic, I think.  If Puppet becomes 
so powerful that it is simply Yet Another Scripting Language, it takes away 
one of the major advantages that I''m relying on.  I work on a team of a
dozen system administrators, and our old methodology of configuring servers 
was that everyone had their own post-install scripts and did everything 
different from everyone else.  I''m relying on Puppet to have a very
clearly
defined idea of how to do certain things so as to stop needless variations 
in practice in our organization.  In my opinion, Less Is More.


-- 
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

>> I don''t see why myclass *should* see that variable. 
I''m a strong
proponent of Puppet being limited in the sense that it encourages more
disciplined approach to configuration instead of "you can do this a
million ways."  I think Puppet was written with that in mind.

Couldn''t agree more.  In a huge conglomerate with large and distributed
teams it can be extremely hard to maintain consistency and standards and
Puppet forces us to.

What I am trying to achieve to to get a handle on the best way to
perform certain tasks.  While I''m happy not using node inheritance and
simply including a class to have my node-specific $vars in scope (as per
earlier messages on this thread), I''m still uncertain as how to deal
with the vast amount of static data we have.  And how to process a load
of static data into another load of static data.

E.g. London -> UK -> Europe -> EMEA

These kind of hierarchies are applicable to multiple classes and I
don''t
want to duplicate case statements, etc.

Worse still, some static data has to be discovered via external scripts
and plugged into the configuration somehow.  Do I create functions or do
I write out files to be IMPORTed???

I also agree that Puppet shouldn''t be a universal scripting language
for
the same reasons.  However, I  have to plug the functionality in
somewhere.

I''m still exploring.  What are your thoughts on the above?

Regards,
Derek
 

-----Original Message-----
From: puppet-users-bounces@madstop.com
[mailto:puppet-users-bounces@madstop.com] On Behalf Of Digant C Kasundra
Sent: 02 May 2007 17:42
To: Puppet User Discussion
Subject: Re: [Puppet-users] Global Variables; related to RFC: Changing
variable override

--On Wednesday, May 02, 2007 08:54:56 +0100
Derek.Whayman@barclayscapital.com wrote:
> node mynode0123 inherits basenode {
>     $var = "mynode0123_specific"
> }
>
> node basenode {
>     include myclass # Do general stuff with a few node-specific tweaks
> }
>
> myclass doesn''t see $var - it is scoped out of existence.
I don''t see why myclass *should* see that variable.  I''m a
strong
proponent of Puppet being limited in the sense that it encourages more
disciplined approach to configuration instead of "you can do this a
million ways."  I think Puppet was written with that in mind.

One of the reasons setting global variables was problematic is what
happens if you tried to set $var in two places that both get parsed for
the node you are evaluating for?  Which takes precident?  With
overrides, you can atleast have some sense of relationship so as to make
that determination, but something of the above would really not make
"object oriented" sense, IMHO.

So, the question that comes to mind is, "What are you trying to
achieve?" 
I have found that often when I have wanted "new features" in Puppet,
it
was because I wanted to force Puppet to think of things *my* way instead
of me thinking of things in *Puppet''s* way.

> I suppose I could define a parser function to imnplement something 
> like "Declared Global Facts" that can retrieve child-scoped 
> information in a parent scope.  But does this make sense given the way
> Puppet''s config is supposed to be architected?  Is Puppet going
that
way?

I would hope not.  That would be problematic, I think.  If Puppet
becomes so powerful that it is simply Yet Another Scripting Language, it
takes away one of the major advantages that I''m relying on.  I work on
a
team of a dozen system administrators, and our old methodology of
configuring servers was that everyone had their own post-install scripts
and did everything different from everyone else.  I''m relying on Puppet
to have a very clearly defined idea of how to do certain things so as to
stop needless variations in practice in our organization.  In my
opinion, Less Is More.


--
Digant C Kasundra <digant@stanford.edu>
Technical Lead, ITS Unix Systems and Applications, Stanford University

_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users
------------------------------------------------------------------------
For important statutory and regulatory disclosures and more information about
Barclays Capital, please visit our web site at http://www.barcap.com.

Internet communications are not secure and therefore the Barclays Group does not
accept legal responsibility for the contents of this message.  Although the
Barclays Group operates anti-virus programmes, it does not accept responsibility
for any damage whatsoever that is caused by viruses being passed.  Any views or
opinions presented are solely those of the author and do not necessarily
represent those of the Barclays Group.  Replies to this email may be monitored
by the Barclays Group for operational or business reasons.

Barclays Capital is the investment banking division of Barclays Bank PLC, a
company registered in England (number 1026167) with its registered office at 1
Churchill Place, London, E14 5HP. This email may relate to or be sent from other
members of the Barclays Group.
------------------------------------------------------------------------

On May 2, 2007, at 11:57 AM, <Derek.Whayman@barclayscapital.com>
wrote:
>
> What I am trying to achieve to to get a handle on the best way to
> perform certain tasks.  While I''m happy not using node inheritance
and
> simply including a class to have my node-specific $vars in scope  
> (as per
> earlier messages on this thread), I''m still uncertain as how to
deal
> with the vast amount of static data we have.  And how to process a  
> load
> of static data into another load of static data.
>
> E.g. London -> UK -> Europe -> EMEA
>
> These kind of hierarchies are applicable to multiple classes and I  
> don''t
> want to duplicate case statements, etc.
You could build a location class that set things appropriately  
($location::city, $location::country), then just use that  
everywhere.  This probably doesn''t fit your exact needs, but if I  
knew how you were planning on using the data, maybe I could do a  
better job of coming up with how to structure it.

In general, though, I completely agree that duplicating case  
statements is a bad idea.
> Worse still, some static data has to be discovered via external  
> scripts
> and plugged into the configuration somehow.  Do I create functions  
> or do
> I write out files to be IMPORTed???
I''ve always maintained that if you need to generate Puppet code,
it''s
a bug.

For centralized static information, functions are the right answer;  
for client-specific info, facts are the answer.
> I also agree that Puppet shouldn''t be a universal scripting  
> language for
> the same reasons.  However, I  have to plug the functionality in
> somewhere.
Yeah, and it doesn''t help that every tool necessarily has its own way  
of mapping out functionality.

  --
  Meeting, n.:
          An assembly of people coming together to decide what person or
          department not represented in the room must solve a problem.
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

On May 2, 2007, at 2:54 AM, <Derek.Whayman@barclayscapital.com>  
<Derek.Whayman@barclayscapital.com> wrote:
> Absolutely, I have the variables inheriting from child scopes
(must''ve
> made a mistake before).  But the problem is that I want something the
> other way around, i.e. to set a variable in a child scope and have it
> referred up to a parent scope (which doesn''t work by design).   
> Actually,
> David Schmitt just posted something to this effect - it seems I''d
> made a
> common mistake.
>
> node mynode0123 inherits basenode {
>     $var = "mynode0123_specific"
> }
>
> node basenode {
>     include myclass # Do general stuff with a few node-specific tweaks
> }
>
> myclass doesn''t see $var - it is scoped out of existence.
I''ve looked at providing this through a ''nodevar''
function you could
use to look up node settings, but it would require a lot of change.

I have plans to push node configurations into a separate tool[1], but  
I was told by someone that he''d be working on that and I
haven''t
heard from him, so I''m about to embark on it myself, I guess, unless  
someone else is interested in picking up the standard.
> I suppose I could define a parser function to imnplement something  
> like
> "Declared Global Facts" that can retrieve child-scoped
information
> in a
> parent scope.  But does this make sense given the way Puppet''s  
> config is
> supposed to be architected?  Is Puppet going that way?
I don''t really understand this statement.  What are you looking to do  
here?  Create variables that are available throughout your  
configuration?

Note that you can have statements outside of any classes or nodes,  
and those statements will evaluate on all nodes, so if you set  
variables in the top scope, they''ll be available everywhere.
> The alternatives are
> (i)   Pull "myclass" from the "basenode" entries and
put it in all of
> the mynode (hostname) node entries - this is what David Schmitt  
> seems to
> be doing
This would definitely get tedious quickly.
> (ii)  The above, plus not extending the node hierarchy down to the
> individual host level (thus keeping the amount of duplication in the
> config files down)
This is somewhat unavoidable in Puppet right now, since your only  
real choices are to use the ''default'' node or to have
node-specific
instances.  Or, of course, to use an external node tool, but that  
can''t set variables (although they should be able to; hmmm).

1 - https://reductivelabs.com/trac/puppet/wiki/ 
ExternalNodeClassification

  --
  I object to doing things that computers can do.  --Olin Shivers
  ---------------------------------------------------------------------
  Luke Kanies | http://reductivelabs.com | http://madstop.com

--On Wednesday, May 02, 2007 17:57:58 +0100 
Derek.Whayman@barclayscapital.com wrote:
> What I am trying to achieve to to get a handle on the best way to
> perform certain tasks.  While I''m happy not using node inheritance
and
> simply including a class to have my node-specific $vars in scope (as per
> earlier messages on this thread), I''m still uncertain as how to
deal
> with the vast amount of static data we have.  And how to process a load
> of static data into another load of static data.
>
> E.g. London -> UK -> Europe -> EMEA
Can you provide a simplified example of what you are trying to pull off?