Puppet users - Feb 2011 - Variable scopes and overriding

In my site.pp I have a var set to false
then I include a per_host module, which sets it for some host, to
true, the intent if for this new value to be used * thereafter*
I put I few notice statement in my manifests, and it seems my var that
get start as false, gets set to true in my per-host module, but is
then back to false in outer modules/classes....

How do you guys achieve what I am trying to do? I guess i don''t
understand var scoping in Puppet....

In site.pp

$auth_aaa = false

In nodes.pp

include module1
include module2

module1: sets $auth_aaa to true
module2: still sees $auth_aaa to false

Thanks a lot.
Mohamed.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Yeah, that''s probably not going to get you where you need to be.

Scope in Puppet goes like this:

* When you declare a variable in a scope, it is local to that scope.
* Every scope has one and only one "parent scope."
    * If it''s a class or node that inherits from a base class/node,
its parent scope is the base class/node.
    * Otherwise, a class or node''s parent scope is the FIRST place
where that class/node was evaluated.
* If you try to evaluate a variable that doesn''t exist in the current
local scope, lookup proceeds through the chain of parent scopes -- its
parent, the parent''s parent, and so on, stopping at the first place it
finds that variable.

In your case, $auth_aaa is going to be true inside module1, but that''s
local to that module. module2 doesn''t have that variable, so
it''s
going to look in its parent scope, which is nodes.pp (well, nodes.pp +
site.pp, because of the way import works), where the variable is
false. Module1 can''t spew its local variables all over its parent
scope, which is by design.

I can''t tell from your description what you''re trying to
accomplish.
I''m guessing you''re ultimately trying to pass a parameter into
a
class, for which the long-term answer is parameterized classes. A lot
of sites aren''t ready to deploy those yet, though, so you have a
couple options:

* Use an external node classifier and set all your parameters at top
scope according to whatever logic you need. All modules will look to
their parent scope and find the right answer for the current node.
* Define a parameters class that conditionally sets a bunch of
variables based on facts like $operatingsystem or whatever. You can
then have read-only access those variables everywhere with their fully-
qualified name. $paramsclass::phppackage, or whatever.
* Include one or two classes that include all your other classes. This
gives you direct control over the parent scopes.

Whichever you do, start trying to think in terms of passing parameters
instead of setting variables. This''ll get you more ready for the
future of the language and will make your designs cleaner.

Hope that helps.
-NF
(docs guy)

On Feb 25, 12:10 pm, Mohamed Lrhazi <lrh...@gmail.com>
wrote:
> In my site.pp I have a var set to false
> then I include a per_host module, which sets it for some host, to
> true, the intent if for this new value to be used * thereafter*
> I put I few notice statement in my manifests, and it seems my var that
> get start as false, gets set to true in my per-host module, but is
> then back to false in outer modules/classes....
>
> How do you guys achieve what I am trying to do? I guess i don''t
> understand var scoping in Puppet....
>
> In site.pp
>
> $auth_aaa = false
>
> In nodes.pp
>
> include module1
> include module2
>
> module1: sets $auth_aaa to true
> module2: still sees $auth_aaa to false
>
> Thanks a lot.
> Mohamed.
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thanks a lot Nick for the detailed response. Not sure I fully
understand yet. I dont think I can use option one because the external
classifier would does not have access to the clients facts. I will
read about parametrized classes and learn to use them, though I dont
yet see how they can solve my immediate need... I am also not sure yet
I understand option three :) Let me describe my immediate need:

I like to have a per-host module, because I love modules, so I dont
use a node definition per host, but just one default node def.

In my site.pp I set all my "global variables'', then include
nodes.pp
In nodes.pp, I have something like:

node ''default'' {

    include "$perhost_module"

    include gu_common
    include gu_auth
...
}

$perhost_module is generated by a function in site.pp, from the $host
fact, to replace dashes with underscores.

In module gu_auth, I have templates that use a variable $auth_aaa,
which I might also need to use similarly elsewhere.

Question:
How do I set my var to a default value for all nodes, but then
customize it in the perhost module.
I can always set it to the default value in each and every perhost
module, but is there another way?

Thanks a lot.
Mohamed.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Fri, Feb 25, 2011 at 3:25 PM, Mohamed Lrhazi <lrhazi@gmail.com>
wrote:
> Thanks a lot Nick for the detailed response. Not sure I fully
> understand yet. I dont think I can use option one because the external
> classifier would does not have access to the clients facts. I will
> read about parametrized classes and learn to use them, though I dont
> yet see how they can solve my immediate need... I am also not sure yet
> I understand option three :) Let me describe my immediate need:
>
> I like to have a per-host module, because I love modules, so I dont
> use a node definition per host, but just one default node def.
>
> In my site.pp I set all my "global variables'', then include
nodes.pp
> In nodes.pp, I have something like:
>
> node ''default'' {
>
>    include "$perhost_module"
>
>    include gu_common
>    include gu_auth
> ...
> }
>
> $perhost_module is generated by a function in site.pp, from the $host
> fact, to replace dashes with underscores.
>
> In module gu_auth, I have templates that use a variable $auth_aaa,
> which I might also need to use similarly elsewhere.
>
> Question:
> How do I set my var to a default value for all nodes, but then
> customize it in the perhost module.
> I can always set it to the default value in each and every perhost
> module, but is there another way?
I''m thinking you are looking to do something like

class perhost_module {
  $auth_aaa = $custom_fact ? {
    "someval" => "override",
    default  => $::auth_aaa
  }
}

class gu_common {
  notice ($perhost_module::auth_aaa)
}

node ''default'' {
   include perhost_module
   include gu_common
}

Thanks,

Nan

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hey, Mohamed. Nan''s got a good suggestion; I'' Alternately, you
could
do this:

node default {
    include $perhost_module
    # Do nothing else.
}

class some_host_module {
    $auth_aaa = "something"
    $other_variable = "something"
    include class_that_includes_everything
}

class class_that_includes_everything {
    include gu_common
    include gu_auth
    # ...Everything else that used to happen in node default
}

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Dammit, I hit send by accident.  Anyway, the point of this is that
Nan''s method is still doing lookup across classes instead of strictly
controlling the parent scopes, and I think building this as a strict
cascade where everything only looks to its direct parent is going to
get you closer to thinking in terms of parameter passing. That''s the
way you should be bending your mind to be ready for the future.

Other things!
* Get rid of nodes.pp, move the default node definition to site.pp.
With as slim as this is and all the meat happening in modules
(especially once you have your class_that_includes_everything up and
running), there''s no good reason to have it in two files.
* I talked to some other people in the office, and they agreed that
doing a module per machine is an idiosyncratic site design that
probably won''t scale too well. While you''re getting this
working, I''d
suggest that you start thinking about other ways to arrange your
site.
* BTW, you CAN access fact data from an ENC. It''s not an official API
(i.e. it''s a filthy hack), but lots of people do it and we''re
looking
to make it a supported design in the future. Nodes send their fact
YAML before the ENC gets called, so you can have it read the fact yaml
out of the master''s cache.


On Feb 26, 12:31 pm, Nick Fagerlund <nick.fagerl...@puppetlabs.com>
wrote:
> Hey, Mohamed. Nan''s got a good suggestion; I''
Alternately, you could
> do this:
>
> node default {
>     include $perhost_module
>     # Do nothing else.
>
> }
>
> class some_host_module {
>     $auth_aaa = "something"
>     $other_variable = "something"
>     include class_that_includes_everything
>
> }
>
> class class_that_includes_everything {
>     include gu_common
>     include gu_auth
>     # ...Everything else that used to happen in node default
>
>
>
>
>
>
>
> }
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Fantastic. Thank you very much guys.

On Sat, Feb 26, 2011 at 3:42 PM, Nick Fagerlund
<nick.fagerlund@puppetlabs.com> wrote:
> Dammit, I hit send by accident.  Anyway, the point of this is that
> Nan''s method is still doing lookup across classes instead of
strictly
> controlling the parent scopes, and I think building this as a strict
> cascade where everything only looks to its direct parent is going to
> get you closer to thinking in terms of parameter passing. That''s
the
> way you should be bending your mind to be ready for the future.
>
> Other things!
> * Get rid of nodes.pp, move the default node definition to site.pp.
> With as slim as this is and all the meat happening in modules
> (especially once you have your class_that_includes_everything up and
> running), there''s no good reason to have it in two files.
> * I talked to some other people in the office, and they agreed that
> doing a module per machine is an idiosyncratic site design that
> probably won''t scale too well. While you''re getting this
working, I''d
> suggest that you start thinking about other ways to arrange your
> site.
> * BTW, you CAN access fact data from an ENC. It''s not an official
API
> (i.e. it''s a filthy hack), but lots of people do it and
we''re looking
> to make it a supported design in the future. Nodes send their fact
> YAML before the ENC gets called, so you can have it read the fact yaml
> out of the master''s cache.
>
>
> On Feb 26, 12:31 pm, Nick Fagerlund <nick.fagerl...@puppetlabs.com>
> wrote:
>> Hey, Mohamed. Nan''s got a good suggestion; I''
Alternately, you could
>> do this:
>>
>> node default {
>>     include $perhost_module
>>     # Do nothing else.
>>
>> }
>>
>> class some_host_module {
>>     $auth_aaa = "something"
>>     $other_variable = "something"
>>     include class_that_includes_everything
>>
>> }
>>
>> class class_that_includes_everything {
>>     include gu_common
>>     include gu_auth
>>     # ...Everything else that used to happen in node default
>>
>>
>>
>>
>>
>>
>>
>> }
>
> --
> You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.