Puppet users - Sep 2010 - best way to include a variable in many modules ?

Hello,

I have two sites with a small number of machines at each.  Each site is 
functionally identical.  I would like to set up a bunch of templates for 
the various services at each site, with a handful of variables that 
indicate which site the service is configured for.  What would be "best 
practice" way to accomplish this in Puppet ?

Consider :

srv1@abc$ facter | grep domain
domain => abc.dom.ain
srv1@abc$ cat /etc/resolv.conf
search abc.dom.ain
10.1.0.1

srv1@xyz$ facter | grep domain
domain => xyz.dom.ain
srv1@abc$ cat /etc/resolv.conf
search xyz.dom.ain
10.2.0.1


Thus i would like a template "resolv.conf.erb" :

search <%= site_name =>.dom.ain
10.<%= site_ip =>.0.1


I _could_ put something like this into _every_ class :

$site_name = $domain ? {
   ''abc.dom.ain'' => ''abc'',
   ''xyz.dom.ain'' => ''xyz'',
}
# etc...

That works, but frankly it''s offensive in every way.  There are clearly
other ways to go about it, so i am curious : for Puppet, what is the 
best practice solution ?

Thank you all for your time and consideration.


-- 
Daniel Maher <dma AT witbe DOT net>
"The Internet is completely over." -- Prince

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

http://projects.puppetlabs.com/projects/1/wiki/Resolv_Conf_Patterns

On Thu, Sep 23, 2010 at 11:36 AM, Daniel Maher <dma@witbe.net> wrote:
> Hello,
>
> I have two sites with a small number of machines at each.  Each site is
> functionally identical.  I would like to set up a bunch of templates for
the
> various services at each site, with a handful of variables that indicate
> which site the service is configured for.  What would be "best
practice" way
> to accomplish this in Puppet ?
>
> Consider :
>
> srv1@abc$ facter | grep domain
> domain => abc.dom.ain
> srv1@abc$ cat /etc/resolv.conf
> search abc.dom.ain
> 10.1.0.1
>
> srv1@xyz$ facter | grep domain
> domain => xyz.dom.ain
> srv1@abc$ cat /etc/resolv.conf
> search xyz.dom.ain
> 10.2.0.1
>
>
> Thus i would like a template "resolv.conf.erb" :
>
> search <%= site_name =>.dom.ain
> 10.<%= site_ip =>.0.1
>
>
> I _could_ put something like this into _every_ class :
>
> $site_name = $domain ? {
>  ''abc.dom.ain'' => ''abc'',
>  ''xyz.dom.ain'' => ''xyz'',
> }
> # etc...
>
> That works, but frankly it''s offensive in every way.  There are
clearly
> other ways to go about it, so i am curious : for Puppet, what is the best
> practice solution ?
>
> Thank you all for your time and consideration.
>
>
> --
> Daniel Maher <dma AT witbe DOT net>
> "The Internet is completely over." -- Prince
>
> --
> 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<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
Tony
http://blog.tonyskapunk.net

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

* Daniel Maher <dma at witbe.net> [2010/09/23
18:36]:
> Consider :
> 
> srv1@abc$ facter | grep domain
> domain => abc.dom.ain
> 
> srv1@xyz$ facter | grep domain
> domain => xyz.dom.ain
>
> Thus i would like a template "resolv.conf.erb" :
> 
> search <%= site_name =>.dom.ain
Why not use:

  search <%= domain %>

?

-- 
Language is not neutral. It is not merely a vehicle which carries
ideas.  It is itself a shaper of ideas.
    -- Dale Spender

-- 
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 24/09/10 1:03 AM, somebody called Tony G. (tonysk8@gmail.com) wrote this:

http://projects.puppetlabs.com/projects/1/wiki/Resolv_Conf_Patterns

On Thu, Sep 23, 2010 at 11:36 AM, Daniel Maher <dma@witbe.net> wrote:
Hello,

I have two sites with a small number of machines at each.  Each site is
functionally identical.  I would like to set up a bunch of templates for the
various services at each site, with a handful of variables that indicate which
site the service is configured for.  What would be "best practice" way
to accomplish this in Puppet ?

Consider :

srv1@abc$ facter | grep domain
domain => abc.dom.ain
srv1@abc$ cat /etc/resolv.conf
search abc.dom.ain
10.1.0.1

srv1@xyz$ facter | grep domain
domain => xyz.dom.ain
srv1@abc$ cat /etc/resolv.conf
search xyz.dom.ain
10.2.0.1


Thus i would like a template "resolv.conf.erb" :

search <%= site_name =>.dom.ain
10.<%= site_ip =>.0.1


I _could_ put something like this into _every_ class :

$site_name = $domain ? {
  ''abc.dom.ain'' => ''abc'',
  ''xyz.dom.ain'' => ''xyz'',
}
# etc...

That works, but frankly it''s offensive in every way.  There are clearly
other ways to go about it, so i am curious : for Puppet, what is the best
practice solution ?

Thank you all for your time and consideration.

Er, unless I''m missing something folks, the OP wasn''t asking
about managing /etc/resolv.conf - AFAICT /etc/resolv.conf was only used by the
OP as an example. How to manage that file in a one-off case it wasn''t
the objective.

So rehashing [paraphrasing mine]: what is Puppet "best practice" for
setting a handful of variables in a single location that then determine the
configuration of each client?

I''m posting because I''m interested in the answer too...and the
answers so far don''t help answer it IMHO. If the answer is in the
documentation somewhere [I know I haven''t found it so far...], well, a
link to that doc would be welcomed for my part.

Regards,
M.
--
Mark Glossop
IT Projects Officer [Murchison Widefield Array Radiotelescope]
ICRAR - International Centre for Radio Astronomy Research
Discovering the hidden Universe through Radio Astronomy
[cid:3368140823_18093341]
E: mark.glossop@icrar.org  |   W: http://icrar.org
 P: +61 [0]8 6488 7744      | RSS: http://icrar.org/news/feed
 M: +61 [0]406 351 336      |  TW: http://twitter.com/icrar

-- 
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 Thu, 23 Sep 2010 18:36:21 +0200, Daniel Maher <dma@witbe.net>
wrote:
> Hello,
> 
> I have two sites with a small number of machines at each.  Each site is 
> functionally identical.  I would like to set up a bunch of templates for 
> the various services at each site, with a handful of variables that 
> indicate which site the service is configured for.  What would be
"best
> practice" way to accomplish this in Puppet ?
Here''s the way we do it, and it works very well for us, while avoiding
"globals" and the associated issues.

First, we have a "basezone" class, which is empty and really is just a
place holder (you''ll see what this is for in a minute):

class bazezone {
}

Next, we define datacenters, so we have something like

class dc1 {
  $var1 = "foo"
  $var2 = "bar"
  include basezone
}

Note how the last thing (and it must be the last thing) it includes is the
basezone.  This is basically the landing area for all variables we define,
so they''re nice and easy to find later.

Next, we have a basenode:

class basenode {
  include role_general
}

The role_general class is stuff we apply to every system, regardless of
where it is.  All of our modules are site-independent, and use templates
extensively.

Finally, we define zones:

class dc1_zone1 {
  include dc1

  $zone_var1 = "hi"
  $zone_var2 = "bye"

  include basenode
}

Zones are common areas inside a datacenter that use similar services - for
instance database servers, web servers, etc. 

Each node then gets assigned to a zone, and that''s it for the most
part.

node ''mysystem'' {
  include dc1_zone1
}

Now, the importance of basezone - when using templates, you have to do a
lookup for the variable.  Having the basezone makes this easy, since all
the variables we define along the way are visible at that level - we
don''t
have to know specific class names.  One example I can share - we use puppet
to manage our root password hash.  For some systems, we override this on a
per-node basis, but for the rest we use the root password that''s
defined
for the zone (Every month we generate a new random 12-character root
password, that''s why we set it per-zone instead of having unique
passwords
everywhere):

# included in role_general
class user_root {
  if ( inline_template("<%=
scope.lookupvar(''root_password'') %>") != ""
) {
    # The root password was over-ridden in the node
    $root_password = inline_template("<%=
scope.lookupvar(''root_password'')
%>")
  }
  else {
    # Use the root password defined in the zone
    $root_password =
inline_template("<%scope.lookupvar(''basezone::root_password'')
%>")
  }
  user { "root":
    uid => 0,
    gid => 0,
    password => "$root_password",
  }
}

If we do ''node "test"
{$root_password="hash"}'' it will use that variable,
otherwise it will pull it out of the higher level classes (either the DC or
the zone).  

So, that''s what we do, and I''ve found it to be reasonably
scalable, and
allows us the ability to deploy generic modules across multiple datacenters
without making any changes.  We can also make modules "zone aware",
which
allows us to do things like give users more permissions in our development
environment while keeping production restricted.

Hope this helps :)

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

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

hello,


----- "Daniel Maher" <dma@witbe.net> wrote:
> Hello,
> 
> I have two sites with a small number of machines at each.  Each site is 
> functionally identical.  I would like to set up a bunch of templates
> for the various services at each site, with a handful of variables that 
> indicate which site the service is configured for.  What would be
> "best practice" way to accomplish this in Puppet ?

You should consider using extlookup.

http://docs.puppetlabs.com/references/2.6.1/function.html#extlookup


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

I created a module with a .pp file containing the following:

#
## Class for dns configuration
#
class resolve-dns{
  include my-dns-resolver::location
  
  file{ ''/etc/resolv.conf'':
    source => $my-dns-resolver::location::resolvesource,
    ensure => present,
    mode   => 644,
    owner  => root,
    group  => root;
  }
}
#
#
class my-dns-resolver::location {
  
  case $domain{
    "site-a": {
      $resolvesource="puppet:///files/etc/resolv.site-a.conf"
    }
    "site-b": {
      $resolvesource="puppet:///files/etc/resolv.site-b.conf"
    }
  }
}

And included my resolve.conf files in my files directory at the above given
path.  

I hope that helps, I would like to see how other people did this.

Greg

On 9/23/10 11:40 AM, "Mark Glossop" <mark.glossop@uwa.edu.au>
wrote:
> On 24/09/10 1:03 AM, somebody called Tony G. (tonysk8@gmail.com) wrote
this:
> 
> http://projects.puppetlabs.com/projects/1/wiki/Resolv_Conf_Patterns
> 
> On Thu, Sep 23, 2010 at 11:36 AM, Daniel Maher <dma@witbe.net> wrote:
> Hello,
> 
> I have two sites with a small number of machines at each.  Each site is
> functionally identical.  I would like to set up a bunch of templates for
the
> various services at each site, with a handful of variables that indicate
which
> site the service is configured for.  What would be "best
practice" way to
> accomplish this in Puppet ?
> 
> Consider :
> 
> srv1@abc$ facter | grep domain
> domain => abc.dom.ain
> srv1@abc$ cat /etc/resolv.conf
> search abc.dom.ain
> 10.1.0.1
> 
> srv1@xyz$ facter | grep domain
> domain => xyz.dom.ain
> srv1@abc$ cat /etc/resolv.conf
> search xyz.dom.ain
> 10.2.0.1
> 
> 
> Thus i would like a template "resolv.conf.erb" :
> 
> search <%= site_name =>.dom.ain
> 10.<%= site_ip =>.0.1
> 
> 
> I _could_ put something like this into _every_ class :
> 
> $site_name = $domain ? {
>   ''abc.dom.ain'' => ''abc'',
>   ''xyz.dom.ain'' => ''xyz'',
> }
> # etc...
> 
> That works, but frankly it''s offensive in every way.  There are
clearly other
> ways to go about it, so i am curious : for Puppet, what is the best
practice
> solution ?
> 
> Thank you all for your time and consideration.
> 
> Er, unless I''m missing something folks, the OP wasn''t
asking about managing
> /etc/resolv.conf - AFAICT /etc/resolv.conf was only used by the OP as an
> example. How to manage that file in a one-off case it wasn''t the
objective.
> 
> So rehashing [paraphrasing mine]: what is Puppet "best practice"
for setting a
> handful of variables in a single location that then determine the
> configuration of each client?
> 
> I''m posting because I''m interested in the answer
too...and the answers so far
> don''t help answer it IMHO. If the answer is in the documentation
somewhere [I
> know I haven''t found it so far...], well, a link to that doc would
be welcomed
> for my part.
> 
> Regards,
> M.
> --
> Mark Glossop
> IT Projects Officer [Murchison Widefield Array Radiotelescope]
> ICRAR - International Centre for Radio Astronomy Research
> Discovering the hidden Universe through Radio Astronomy
> [cid:3368140823_18093341]
> E: mark.glossop@icrar.org  |   W: http://icrar.org
>  P: +61 [0]8 6488 7744      | RSS: http://icrar.org/news/feed
>  M: +61 [0]406 351 336      |  TW: http://twitter.com/icrar
-- 
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 Sep 23, 9:36 am, Daniel Maher <d...@witbe.net>
wrote:
> Hello,
>
> I have two sites with a small number of machines at each.  Each site is
> functionally identical.  I would like to set up a bunch of templates for
> the various services at each site, with a handful of variables that
> indicate which site the service is configured for.  What would be
"best
> practice" way to accomplish this in Puppet ?
>
> Consider :
>
> srv1@abc$ facter | grep domain
> domain => abc.dom.ain
> srv1@abc$ cat /etc/resolv.conf
> search abc.dom.ain
> 10.1.0.1
>
> srv1@xyz$ facter | grep domain
> domain => xyz.dom.ain
> srv1@abc$ cat /etc/resolv.conf
> search xyz.dom.ain
> 10.2.0.1
>
> Thus i would like a template "resolv.conf.erb" :
>
> search <%= site_name =>.dom.ain
> 10.<%= site_ip =>.0.1
>
> I _could_ put something like this into _every_ class :
>
> $site_name = $domain ? {
>    ''abc.dom.ain'' => ''abc'',
>    ''xyz.dom.ain'' => ''xyz'',}
>
> # etc...
>
> That works, but frankly it''s offensive in every way.  There are
clearly
> other ways to go about it, so i am curious : for Puppet, what is the
> best practice solution ?
>
> Thank you all for your time and consideration.
>
> --
> Daniel Maher <dma AT witbe DOT net>
> "The Internet is completely over." -- Prince
I have code available that might work for you, since I manage
different sites as well as pre-production environments (as opposed to
puppet''s internal understanding of environments) by grouping them
together by each site or POP[1]. Check out my site manifest[2]. It
references $pop which corresponds to your $site_name. The code to use
$pop is in the generic module[3].

It is preferable to have your variables listed in one place, like the
site manifest, than to use ::location which would scatter your
variables throughout your modules and lead to lots of code duplication
with respect to case statements.

-g

[1] - http://en.wikipedia.org/wiki/Point_of_Presence
[2] - http://github.com/ghoneycutt/puppet-sitemanifest/blob/master/site.pp
[3] - http://forge.puppetlabs.com/ghoneycutt/generic

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

I accomplish this with a Environment variable.  First you define 
environments like PROD/PRE and then for each machine in an environment you 
simply define that one variable  (which for me is gather from an app 
definition).

Than I setup a template for each environment.

--------------------------------------------------
From: "Mark Glossop" <mark.glossop@uwa.edu.au>
Sent: Thursday, September 23, 2010 12:40 PM
To: "Puppet Users" <puppet-users@googlegroups.com>
Subject: Re: [Puppet Users] best way to include a variable in many modules ?
> On 24/09/10 1:03 AM, somebody called Tony G. (tonysk8@gmail.com) wrote 
> this:
>
> http://projects.puppetlabs.com/projects/1/wiki/Resolv_Conf_Patterns
>
> On Thu, Sep 23, 2010 at 11:36 AM, Daniel Maher <dma@witbe.net> wrote:
> Hello,
>
> I have two sites with a small number of machines at each.  Each site is 
> functionally identical.  I would like to set up a bunch of templates for 
> the various services at each site, with a handful of variables that 
> indicate which site the service is configured for.  What would be
"best
> practice" way to accomplish this in Puppet ?
>
> Consider :
>
> srv1@abc$ facter | grep domain
> domain => abc.dom.ain
> srv1@abc$ cat /etc/resolv.conf
> search abc.dom.ain
> 10.1.0.1
>
> srv1@xyz$ facter | grep domain
> domain => xyz.dom.ain
> srv1@abc$ cat /etc/resolv.conf
> search xyz.dom.ain
> 10.2.0.1
>
>
> Thus i would like a template "resolv.conf.erb" :
>
> search <%= site_name =>.dom.ain
> 10.<%= site_ip =>.0.1
>
>
> I _could_ put something like this into _every_ class :
>
> $site_name = $domain ? {
>  ''abc.dom.ain'' => ''abc'',
>  ''xyz.dom.ain'' => ''xyz'',
> }
> # etc...
>
> That works, but frankly it''s offensive in every way.  There are
clearly
> other ways to go about it, so i am curious : for Puppet, what is the best 
> practice solution ?
>
> Thank you all for your time and consideration.
>
> Er, unless I''m missing something folks, the OP wasn''t
asking about
> managing /etc/resolv.conf - AFAICT /etc/resolv.conf was only used by the 
> OP as an example. How to manage that file in a one-off case it
wasn''t the
> objective.
>
> So rehashing [paraphrasing mine]: what is Puppet "best practice"
for
> setting a handful of variables in a single location that then determine 
> the configuration of each client?
>
> I''m posting because I''m interested in the answer
too...and the answers so
> far don''t help answer it IMHO. If the answer is in the
documentation
> somewhere [I know I haven''t found it so far...], well, a link to
that doc
> would be welcomed for my part.
>
> Regards,
> M.
> --
> Mark Glossop
> IT Projects Officer [Murchison Widefield Array Radiotelescope]
> ICRAR - International Centre for Radio Astronomy Research
> Discovering the hidden Universe through Radio Astronomy
> [cid:3368140823_18093341]
> E: mark.glossop@icrar.org  |   W: http://icrar.org
> P: +61 [0]8 6488 7744      | RSS: http://icrar.org/news/feed
> M: +61 [0]406 351 336      |  TW: http://twitter.com/icrar
>
> -- 
> 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.

On 09/23/2010 08:40 PM, Mark Glossop wrote:
> Er, unless I''m missing something folks, the OP wasn''t
asking about managing /etc/resolv.conf - AFAICT /etc/resolv.conf was only used
by the OP as an example. How to manage that file in a one-off case it
wasn''t the objective.
>
> So rehashing [paraphrasing mine]: what is Puppet "best practice"
for setting a handful of variables in a single location that then determine the
configuration of each client?
>
> I''m posting because I''m interested in the answer
too...and the answers so far don''t help answer it IMHO. If the answer
is in the documentation somewhere [I know I haven''t found it so
far...], well, a link to that doc would be welcomed for my part.
Precisely : i provided resolv.conf as an example because it is simple, 
and it highlighted what i was trying to accomplish.  In retrospect, 
perhaps i should not have picked an example for which there was already 
a particular module. :P


-- 
Daniel Maher <dma AT witbe DOT net>
"The Internet is completely over." -- Prince

-- 
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 09/23/2010 09:06 PM, James Cammarata wrote:
> Here''s the way we do it, and it works very well for us, while
avoiding
> "globals" and the associated issues.
>
> First, we have a "basezone" class, which is empty and really is
just a
> place holder (you''ll see what this is for in a minute):
Thanks for the reply !

Simplifying your example, then :

class foo {
   $foo_var = "beer"
}

class bar {
   include foo
   # we could assign it here...
   $bar_var = $::foo::foo_var
   file { ''template'':
     content => template(''bar/template.erb'')
   }
}


With "template.erb":

This is foo_var as determined by bar : <%= bar_var =>
Or directly from foo : <%= scope.lookupvar(''foo::foo_var'')
%>


Applying this distilled example to my previously stated scenario, then, 
we might have something like :

# include this where appropriate
class getsite {
   $site_name = $domain ? {
     ''abc.dom.ain'' => ''abc'',
     ''xyz.dom.ain'' => ''xyz'',
   }
   $site_ip = $domain ? {
     ''abc.dom.ain'' => ''1'',
     ''xyz.dom.ain'' => ''2'',
   }
}

# yes i know there''s a module for this; this is just a contrived
example
class resolv {
   include getsite
   file { ''/etc/resolv.conf:
     content => template(''resolv/resolv.conf.erb'')
   }
}


With template "resolv.conf.erb" :
search <%= scope.lookupvar(''getsite::site_name'')
%>.dom.ain
server 10.<%= scope.lookupvar(''getsite::site_ip'') %>.0.1


This works exactly as it appears, and is a reasonable approach, though 
in my example scenario the scope is limited ; i would harbour concerns 
about tracking this though many levels of scope (as you have) without 
proper internal documentation. :)

Thanks for the idea !

-- 
Daniel Maher <dma AT witbe DOT net>
"The Internet is completely over." -- Prince

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

> This works exactly as it appears, and is a reasonable approach, though 
> in my example scenario the scope is limited ; i would harbour concerns 
> about tracking this though many levels of scope (as you have) without 
> proper internal documentation. :)
That''s the good thing about the way we do it - there''s only
one level of
scope: basezone.  Every variable we define in all the classes along the way
is visible at that level, so we don''t have to remember class names of
all
the stuff in the middle.  Your version makes things more complex, because
you have to remember that your domain variable is in getsite.  Also, I
don''t think you''d be able to include getsite more than once -
I think you''d
get a variable redefinition error.  And we do try and use puppetdoc to
explain class internals as much as possible, so the new guys know what
classes they need to include.  

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

-- 
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 09/24/2010 02:57 PM, James Cammarata wrote:
> That''s the good thing about the way we do it - there''s
only one level of
> scope: basezone.  Every variable we define in all the classes along the way
> is visible at that level, so we don''t have to remember class names
of all
> the stuff in the middle.  Your version makes things more complex, because
> you have to remember that your domain variable is in getsite.  Also, I
> don''t think you''d be able to include getsite more than
once - I think you''d
> get a variable redefinition error.  And we do try and use puppetdoc to
> explain class internals as much as possible, so the new guys know what
> classes they need to include.
Some interesting points, to be sure.  As for including getsite more than 
once, consider :

class getsite {
   # method to obtain $site_name goes here
}

class foo {
   include getsite
   file { ''template'':
     content => template(''foo/template.erb'')
   }
}

class bar {
   include getsite
   file { ''template'':
     content => template(''bar/template.erb'')
   }
}

node ''srv1'' {
   include foo
   include bar
}

node ''srv2'' {
   include foo
   include bar
}

# <bar|foo>/template.erb
Site is : <%= scope.lookupvar(''getsite::site_name'') %>
# EOF


That works - i just tried it.  No problems.  In fact, this works, too :

class bar {
   include getsite
   include foo         # which already has getsite in it
}


If the value of "$site_name" were to change depending on which class
was
calling it, then i could see that being a problem - but that doesn''t 
happen in this case.


In any case, looking back at your original reply, i am getting a little 
lost on the logic.  I drew your include relationships out on the 
whiteboard here and it doesn''t quite make sense to me ; i''ll
try to
re-create it here (i hope your client uses a fixed-width font :) ).

.---------------------------------------------------.
| class dc1_zone1                                   |
| .--------------------. .------------------------. |
| | class dc1          | | class basenode         | |
| | .----------------. | | .--------------------. | |
| | | class basezone | | | | class role_general | | |
| | ''----------------'' | |
''--------------------'' | |
| ''--------------------''
''------------------------'' |
''---------------------------------------------------''

Breaking the scopes down :
dc1_zone1 : All variables in all classes
dc1 : Variables in dc1 and basezone only
basezone : Variables in basezone only
basenode : All variables in basenode and role_general
role_general : All variables in role_general

Your stated example includes logic from role_general, which in turn 
looks for a variable in basezone.  This leads to two questions :
1. If basezone is empty (a place holder, as you mentioned), where is the 
variable coming from ?
2. How can role_general go look for a variable that is outside of its 
scope ?

For question #2, i am hypothesising that the variable is out of scope, 
but that the ruby call to scope.lookupvar somehow deals with that 
problem, and "finds" the variable anyway ?

Alternatively, i have completely and utterly misunderstood the 
fundamentals of scoping in Puppet (eminently possible).  Is it that 
given the class relationship described above, role_general has access to 
basezone''s scope because they are both "included" together at
a higher
level ?

Thank you for your continued commentary on this topic.


-- 
Daniel Maher <dma AT witbe DOT net>
"The Internet is completely over." -- Prince

-- 
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 09/23/2010 09:31 PM, R.I.Pienaar wrote:
>> I have two sites with a small number of machines at each.  Each site is
>> functionally identical.  I would like to set up a bunch of templates
>> for the various services at each site, with a handful of variables that
>> indicate which site the service is configured for.  What would be
>> "best practice" way to accomplish this in Puppet ?
>
>
> You should consider using extlookup.
>
> http://docs.puppetlabs.com/references/2.6.1/function.html#extlookup
Thank you for your reply !

According to the documentation, extlookup reads from csv files, which 
means that a given csv file with the desired data must already be 
present ; therefore another mechanism must create the file before 
extlookup can become useful.

I''ve taken a look at your blog entry here, which was very helpful in 
explaining the situation :
http://www.devco.net/archives/2009/08/31/complex_data_and_puppet.php

Your entry does not, however, indicate where the csv comes from in the 
first place ; in my stated case, i suppose that the csv would need to be 
generated dynamically.  One could have a class that ensures a shell 
script that gets exec''d, the output of which is a csv file that has :
site_name,<value>

Then you could extlookup that csv file in order to provide the desired 
variable.

That seems awkward, though only because i''d be going through the bother
of dynamically generating a csv for one value ; i could see how this 
would be (very) useful if i was gathering tonnes of variables to use in 
this way.

-- 
Daniel Maher <dma AT witbe DOT net>
"The Internet is completely over." -- Prince

-- 
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 Thu, Sep 23, 2010 at 08:31:26PM +0100, R.I.Pienaar
wrote:
> > I have two sites with a small number of machines at each.  Each site
is
> > functionally identical.  I would like to set up a bunch of templates
> > for the various services at each site, with a handful of variables
that
> > indicate which site the service is configured for.  What would be
> > "best practice" way to accomplish this in Puppet ?
> 
> 
> You should consider using extlookup.
> 
> http://docs.puppetlabs.com/references/2.6.1/function.html#extlookup
Why?  It seems odd to be stepping outside the puppet DSL for something
so basic.

-- 
Bruce

If the universe were simple enough to be understood, we would be too
simple to understand it.

-- 
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 Sun, Sep 26, 2010 at 9:44 AM, Bruce Richardson
<itsbruce@workshy.org>wrote:
> On Thu, Sep 23, 2010 at 08:31:26PM +0100, R.I.Pienaar wrote:
> > > I have two sites with a small number of machines at each.  Each
site is
> > > functionally identical.  I would like to set up a bunch of
templates
> > > for the various services at each site, with a handful of
variables that
> > > indicate which site the service is configured for.  What would be
> > > "best practice" way to accomplish this in Puppet ?
> >
> >
> > You should consider using extlookup.
> >
> > http://docs.puppetlabs.com/references/2.6.1/function.html#extlookup
>
> Why?  It seems odd to be stepping outside the puppet DSL for something
> so basic.

The same could be said for puppet''s awful variable scoping. Should be
simple, but it''s not. I''d be dead without extlookup.

Doug.

-- 
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 Sun, Sep 26, 2010 at 2:01 PM, Douglas Garstang
<doug.garstang@gmail.com> wrote:
> On Sun, Sep 26, 2010 at 9:44 AM, Bruce Richardson
<itsbruce@workshy.org>
> wrote:
>>
>> On Thu, Sep 23, 2010 at 08:31:26PM +0100, R.I.Pienaar wrote:
>> > > I have two sites with a small number of machines at each.
 Each site
>> > > is
>> > > functionally identical.  I would like to set up a bunch of
templates
>> > > for the various services at each site, with a handful of
variables
>> > > that
>> > > indicate which site the service is configured for.  What
would be
>> > > "best practice" way to accomplish this in Puppet ?
>> >
>> >
>> > You should consider using extlookup.
>> >
>> >
http://docs.puppetlabs.com/references/2.6.1/function.html#extlookup
>>
>> Why?  It seems odd to be stepping outside the puppet DSL for something
>> so basic.
>
> The same could be said for puppet''s awful variable scoping. Should
be
> simple, but it''s not. I''d be dead without extlookup.

Doug, have we got any bug reports or feature requests from you about this yet?

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