thr3ads.net - Puppet users - [Puppet Users] Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables [Apr 2012]

If this information is useful, please help other people find it:
Share via:

Calimero

2012-Apr-24 13:19 UTC

[Puppet Users] Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

Hi,

I worked with puppet (< 0.25) back in 2008/2009. We were able to
deploy 200 servers from scratch and manage them. It worked fine.

I''m now with a new customer and I''m pushing Puppet (and
I''m also back
to puppet on a side project).

We''re considering Puppet 2.6 to manage RHEL/CentOS 5 or 6 hosts.
I''m
"upgrading myself" to Puppet 2.6''s new concepts and features.

Anyway consider this for the sake of argument:

- node server1.hostingcompanyAlpha.com
-- hosted on a dedicated server at provider Alpha
-- production

- node server2.hostingcompanyBeta.net
-- hosted on a dedicated server at provider Beta
-- production

- node staging.myprivatenetwork.priv
-- hosted on my customer''s private network
-- staging/QA

- node dev.myprivatenetwork.priv
-- hosted on my customer''s private network
-- development server

Those four nodes must host the same elements:
- Apache HTTPD with multiple VHosts
- PHP
- Extra software ...


There are a few differences between nodes:
- Servers don''t have the same capabilities (CPU/Mem/bandwidth): we
need to tweak Apache''s MaxClients settings on a per-host basis
- We need to tweak PHP : displaying errors on ''staging'' and
''dev'' but
hiding them on server1/server2 (ie: setting ''display_errors''
to ''on''
or ''off'' in php.ini)
- On development and staging/testing servers we need to change some of
the VHosts definitions: add extra serverAliases, etc ...
- server1, server2 and staging/dev must use different DNS servers (/
etc/resolv.conf) and RPM Mirrors (yumrepo{ })

I''ve read the following blog post:
http://puppetlabs.com/blog/the-problem-with-separating-data-from-puppet-code/



Back with puppet < 0.25, we''d use "global variables" (not
even node
inheritance).

manifest/sites.pp had something like:

$envname = ''prod''
$envstr = ''''
$dns_servers = [ ''10.0.0.42'', ''10.10.1.42'' ]

import "classes/*.pp"

node ''server1.hostingcompanyAlpha.com'' {

	$httpd_maxclients = 300
	$yum_base = "http://mirrors.hostingcompanyAlpha.com/ftp.centos.org/"
	$dns_servers = [ ''1.2.3.4'', ''1.2.4.4'' ] #
Hosting Co.''s resolvers


	include mywebserver
}

node ''server2.hostingcompanyBeta.net'' {

	$httpd_maxclients = 200
	$yum_base = "http://repo.hostingcompanyBeta.net/centos/"
	$dns_servers = [ ''8.8.8.8.8'' , ''8.8.4.4'' ]


	include mywebserver
}

node ''staging.myprivatenetwork.priv'' {

	$httpd_maxclients = 50
	$php_display_errors = ''on''
	$envname = ''staging''
	$envstr = ''stag''

	include mywebserver
}


node ''dev.myprivatenetwork.priv'' {

	$httpd_maxclients = 20
	$php_error_reporting = "E_ALL"
	$php_display_errors = ''on''
	$envname = ''dev''
	$envstr = ''dev''

	include mywebserver
}

manifests/classes/mywebserver.pp would contain somethine like this:

import "php"
import "httpd"

class mywebserver {

	include centos # which would in turn include modules ''yum''
and
''resolv''

	include httpd
	include php
	include php::apc

	define httpd::vhost { ''mysite'' :
		servername	=> "www.mysite.com",
		documentroot	=> "/var/www/html/mysite.com",
	}
}



modules/httpd/manifests/init.pp had:

# defaults
$httpd_maxclients = 150
$httpd_...

class httpd {

	file { "/etc/httpd/conf/httpd.conf" :
		content	=> template("httpd/httpd.conf.default.erb"); # which
would
then use $httpd_maxclients
	}

}

We also had a httpd::vhost($ip = "*", $port = 80, $servername,
$documentroot, ...) define which would write VHosts files based on the
following template:

<VirtualHost <%= ip %>:<%= port%>>
	ServerName	<%= servername %>
<% if envstr != '''' -%>
	ServerAlias	<%= envstr %><%= servername %>
<% end -%>

<% if envname != ''prod'' -%>
	php_admin_value display_errors on
<% end -%>

...
</VirtualHost>


modules/yum/manifests/init.pp had:

# defaults
$yum_base = "http://myrepo.myprivatenetwork.priv/centos"

class yum {
	yumrep { "os" :
		baseurl = "${yum_base}/RPMS.os",
	}
}


modules/php/manifests/init.pp:

php_memory_limit = "32M"
php_error_reporting = "..."
php_display_errors = "off"
and so on ... (huge list)

with php.ini.erb :

display_errors = <%= php_display_errors %>
error_reporting = <%= php_error_reporting %>
...


And so on ... If you haven''t dozed off already, you get the idea. :-)

That way we could provide safe/sane default settings which could
easily be tweaked on a per-host or per-class basis.

Parameters were quite easy to track and were in the code (which is
stored in SVN). There might be some scoping problems from time to
time, I have to admit. But once we had our "pattern", things would be
smooth.



I do now have trouble understanding how I should proceed with Puppet
2.6 (and 2.7 in the future), if I''m to avoid global variables.

Parameterized class are seemingly not an option and, from what I
understand and read, are more of an alternative to class inheritance
(Nigel Kersten''s comment on issue #13537): you don''t need to
inherit
from a parent class if you want to tweak some of the ressources, you
could just pass parameters to your class in the first place.
Indeed I do not see how parameterized classes would help me get such
flexibility. Or I''d have to "pass down" all the variables I
need from
my node/host down to every class. Cumbersome, at best.
Parameterized class a good for "coarse grained" tuning, but not
"per
host" tweaks" on a variety of items.


Next option is an External Node Classifier which I would have to
develop and maintain to fetch/rewrite/generate/whatever variables I
need. I could probably get what I want but I''d end up having an extra
tool to maintain (and train people to use).

A "middle of the road" option would be Hiera and create a hierarchy
base on the ''$hostname'' fact (yaml backed for
''custom'' values, and
probably a puppet backed to fetch the defaults ? I see that you can
also pass a default value to hiera()) . I assume that''s the way to go.

Well... I''m a bit puzzled by all this. :-)

I''d like some input from you guys (and gals !).

I''ll try and install Hiera (nice, more stuff I need to package !)
anyway. By the way what''s the target version (2.8 ?) for
Hiera''s
integration into Puppet ?

Thanks !
G.

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

Ashley Penney

2012-Apr-24 13:34 UTC

head link

Re: [Puppet Users] Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

This was a long email!  The answer to your problems is definitely something
like
Hiera.  You make a common.yaml that has all your "defaults" and then
you can
overwrite these based on any fact you like, when building the hierarchy.
 You can
make a hierarchy like:

fqdn
environment
common.yaml

Then you could make

environment/staging.yaml
fqdn/server1.yaml

And override any of the "defaults" in common.yaml with more specific
values.  You even
just set something like php_errors: true in staging.yaml and then in the
template have
some kind of <% if php_errors %> log with errors <% end %> etc kind
of
code.  Hiera
is definitely the solution to what you''re trying to do, it lets you
extract
all that magic
out of the manifests and keep them clean and then rely on looking for the
most specific
match when traversing down the hierarchy.

On Tue, Apr 24, 2012 at 9:19 AM, Calimero <calimero.ng@evolutive.org>
wrote:
> Hi,
>
> I worked with puppet (< 0.25) back in 2008/2009. We were able to
> deploy 200 servers from scratch and manage them. It worked fine.
>
> I''m now with a new customer and I''m pushing Puppet (and
I''m also back
> to puppet on a side project).
>
> We''re considering Puppet 2.6 to manage RHEL/CentOS 5 or 6 hosts.
I''m
> "upgrading myself" to Puppet 2.6''s new concepts and
features.
>
> Anyway consider this for the sake of argument:
>
> - node server1.hostingcompanyAlpha.com
> -- hosted on a dedicated server at provider Alpha
> -- production
>
> - node server2.hostingcompanyBeta.net
> -- hosted on a dedicated server at provider Beta
> -- production
>
> - node staging.myprivatenetwork.priv
> -- hosted on my customer''s private network
> -- staging/QA
>
> - node dev.myprivatenetwork.priv
> -- hosted on my customer''s private network
> -- development server
>
> Those four nodes must host the same elements:
> - Apache HTTPD with multiple VHosts
> - PHP
> - Extra software ...
>
>
> There are a few differences between nodes:
> - Servers don''t have the same capabilities (CPU/Mem/bandwidth): we
> need to tweak Apache''s MaxClients settings on a per-host basis
> - We need to tweak PHP : displaying errors on ''staging''
and ''dev'' but
> hiding them on server1/server2 (ie: setting
''display_errors'' to ''on''
> or ''off'' in php.ini)
> - On development and staging/testing servers we need to change some of
> the VHosts definitions: add extra serverAliases, etc ...
> - server1, server2 and staging/dev must use different DNS servers (/
> etc/resolv.conf) and RPM Mirrors (yumrepo{ })
>
> I''ve read the following blog post:
>
>
http://puppetlabs.com/blog/the-problem-with-separating-data-from-puppet-code/
>
>
>
> Back with puppet < 0.25, we''d use "global variables"
(not even node
> inheritance).
>
> manifest/sites.pp had something like:
>
> $envname = ''prod''
> $envstr = ''''
> $dns_servers = [ ''10.0.0.42'',
''10.10.1.42'' ]
>
> import "classes/*.pp"
>
> node ''server1.hostingcompanyAlpha.com'' {
>
>        $httpd_maxclients = 300
>        $yum_base =
"http://mirrors.hostingcompanyAlpha.com/ftp.centos.org/
> "
>        $dns_servers = [ ''1.2.3.4'',
''1.2.4.4'' ] # Hosting Co.''s resolvers
>
>
>        include mywebserver
> }
>
> node ''server2.hostingcompanyBeta.net'' {
>
>        $httpd_maxclients = 200
>        $yum_base = "http://repo.hostingcompanyBeta.net/centos/"
>        $dns_servers = [ ''8.8.8.8.8'' ,
''8.8.4.4'' ]
>
>
>        include mywebserver
> }
>
> node ''staging.myprivatenetwork.priv'' {
>
>        $httpd_maxclients = 50
>        $php_display_errors = ''on''
>        $envname = ''staging''
>        $envstr = ''stag''
>
>        include mywebserver
> }
>
>
> node ''dev.myprivatenetwork.priv'' {
>
>        $httpd_maxclients = 20
>        $php_error_reporting = "E_ALL"
>        $php_display_errors = ''on''
>        $envname = ''dev''
>        $envstr = ''dev''
>
>        include mywebserver
> }
>
> manifests/classes/mywebserver.pp would contain somethine like this:
>
> import "php"
> import "httpd"
>
> class mywebserver {
>
>        include centos # which would in turn include modules
''yum'' and
> ''resolv''
>
>        include httpd
>        include php
>        include php::apc
>
>        define httpd::vhost { ''mysite'' :
>                servername      => "www.mysite.com",
>                documentroot    => "/var/www/html/mysite.com",
>        }
> }
>
>
>
> modules/httpd/manifests/init.pp had:
>
> # defaults
> $httpd_maxclients = 150
> $httpd_...
>
> class httpd {
>
>        file { "/etc/httpd/conf/httpd.conf" :
>                content =>
template("httpd/httpd.conf.default.erb"); #
> which would
> then use $httpd_maxclients
>        }
>
> }
>
> We also had a httpd::vhost($ip = "*", $port = 80, $servername,
> $documentroot, ...) define which would write VHosts files based on the
> following template:
>
> <VirtualHost <%= ip %>:<%= port%>>
>        ServerName      <%= servername %>
> <% if envstr != '''' -%>
>        ServerAlias     <%= envstr %><%= servername %>
> <% end -%>
>
> <% if envname != ''prod'' -%>
>        php_admin_value display_errors on
> <% end -%>
>
> ...
> </VirtualHost>
>
>
> modules/yum/manifests/init.pp had:
>
> # defaults
> $yum_base = "http://myrepo.myprivatenetwork.priv/centos"
>
> class yum {
>        yumrep { "os" :
>                baseurl = "${yum_base}/RPMS.os",
>        }
> }
>
>
> modules/php/manifests/init.pp:
>
> php_memory_limit = "32M"
> php_error_reporting = "..."
> php_display_errors = "off"
> and so on ... (huge list)
>
> with php.ini.erb :
>
> display_errors = <%= php_display_errors %>
> error_reporting = <%= php_error_reporting %>
> ...
>
>
> And so on ... If you haven''t dozed off already, you get the idea.
:-)
>
> That way we could provide safe/sane default settings which could
> easily be tweaked on a per-host or per-class basis.
>
> Parameters were quite easy to track and were in the code (which is
> stored in SVN). There might be some scoping problems from time to
> time, I have to admit. But once we had our "pattern", things
would be
> smooth.
>
>
>
> I do now have trouble understanding how I should proceed with Puppet
> 2.6 (and 2.7 in the future), if I''m to avoid global variables.
>
> Parameterized class are seemingly not an option and, from what I
> understand and read, are more of an alternative to class inheritance
> (Nigel Kersten''s comment on issue #13537): you don''t need
to inherit
> from a parent class if you want to tweak some of the ressources, you
> could just pass parameters to your class in the first place.
> Indeed I do not see how parameterized classes would help me get such
> flexibility. Or I''d have to "pass down" all the
variables I need from
> my node/host down to every class. Cumbersome, at best.
> Parameterized class a good for "coarse grained" tuning, but not
"per
> host" tweaks" on a variety of items.
>
>
> Next option is an External Node Classifier which I would have to
> develop and maintain to fetch/rewrite/generate/whatever variables I
> need. I could probably get what I want but I''d end up having an
extra
> tool to maintain (and train people to use).
>
> A "middle of the road" option would be Hiera and create a
hierarchy
> base on the ''$hostname'' fact (yaml backed for
''custom'' values, and
> probably a puppet backed to fetch the defaults ? I see that you can
> also pass a default value to hiera()) . I assume that''s the way to
go.
>
> Well... I''m a bit puzzled by all this. :-)
>
> I''d like some input from you guys (and gals !).
>
> I''ll try and install Hiera (nice, more stuff I need to package !)
> anyway. By the way what''s the target version (2.8 ?) for
Hiera''s
> integration into Puppet ?
>
> Thanks !
> G.
>
> --
> 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.

Calimero

2012-Apr-24 15:55 UTC

head link

[Puppet Users] Re: Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

On 24 avr, 15:34, Ashley Penney <apen...@gmail.com>
wrote:> This was a long email!
Yeah, I know it might get a few "TL;DR" but I wanted to provided all
relevant information. :)
> The answer to your problems is definitely something
> like
> Hiera.  You make a common.yaml that has all your "defaults" and
then you can
> overwrite these based on any fact you like, when building the hierarchy.
>  You can
> make a hierarchy like:
>
> fqdn
> environment
> common.yaml
That''s the part I don''t really get so far, as I
haven''t fiddled with
Hiera yet.

How would Hiera search through the hierarchy ?

Try: fqdn/server1.yml
==> not found
Try: environment/staging.yml
==> not found
Fetch from common.yml

Or:
Try server1/staging.yml
==> not found
Fetch from common.yml

ie: is it "recursive" or it a list of "fallbacks" ?
> Then you could make
>
> environment/staging.yaml
> fqdn/server1.yaml
I assume this matches matches my first example.

Thanks for your help,
G.

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

jcbollinger

2012-Apr-24 16:40 UTC

head link

[Puppet Users] Re: Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

On Apr 24, 8:19 am, Calimero <calimero...@evolutive.org>
wrote:> Hi,
>
> I worked with puppet (< 0.25) back in 2008/2009. We were able to
> deploy 200 servers from scratch and manage them. It worked fine.
>
> I''m now with a new customer and I''m pushing Puppet (and
I''m also back
> to puppet on a side project).
>
> We''re considering Puppet 2.6 to manage RHEL/CentOS 5 or 6 hosts.
I''m
> "upgrading myself" to Puppet 2.6''s new concepts and
features.
>
> Anyway consider this for the sake of argument:
>
> - node server1.hostingcompanyAlpha.com
> -- hosted on a dedicated server at provider Alpha
> -- production
>
> - node server2.hostingcompanyBeta.net
> -- hosted on a dedicated server at provider Beta
> -- production
>
> - node staging.myprivatenetwork.priv
> -- hosted on my customer''s private network
> -- staging/QA
>
> - node dev.myprivatenetwork.priv
> -- hosted on my customer''s private network
> -- development server
>
> Those four nodes must host the same elements:
> - Apache HTTPD with multiple VHosts
> - PHP
> - Extra software ...
>
> There are a few differences between nodes:
> - Servers don''t have the same capabilities (CPU/Mem/bandwidth): we
> need to tweak Apache''s MaxClients settings on a per-host basis
> - We need to tweak PHP : displaying errors on ''staging''
and ''dev'' but
> hiding them on server1/server2 (ie: setting
''display_errors'' to ''on''
> or ''off'' in php.ini)
> - On development and staging/testing servers we need to change some of
> the VHosts definitions: add extra serverAliases, etc ...
> - server1, server2 and staging/dev must use different DNS servers (/
> etc/resolv.conf) and RPM Mirrors (yumrepo{ })
>
> I''ve read the following blog
post:http://puppetlabs.com/blog/the-problem-with-separating-data-from-pupp...
>
> Back with puppet < 0.25, we''d use "global variables"
(not even node
> inheritance).
>
> manifest/sites.pp had something like:
>
> $envname = ''prod''
> $envstr = ''''
> $dns_servers = [ ''10.0.0.42'',
''10.10.1.42'' ]
>
> import "classes/*.pp"
>
> node ''server1.hostingcompanyAlpha.com'' {
>
>         $httpd_maxclients = 300
>         $yum_base =
"http://mirrors.hostingcompanyAlpha.com/ftp.centos.org/"
>         $dns_servers = [ ''1.2.3.4'',
''1.2.4.4'' ] # Hosting Co.''s resolvers
>
>         include mywebserver
>
> }
>
> node ''server2.hostingcompanyBeta.net'' {
>
>         $httpd_maxclients = 200
>         $yum_base = "http://repo.hostingcompanyBeta.net/centos/"
>         $dns_servers = [ ''8.8.8.8.8'' ,
''8.8.4.4'' ]
>
>         include mywebserver
>
> }
>
> node ''staging.myprivatenetwork.priv'' {
>
>         $httpd_maxclients = 50
>         $php_display_errors = ''on''
>         $envname = ''staging''
>         $envstr = ''stag''
>
>         include mywebserver
>
> }
>
> node ''dev.myprivatenetwork.priv'' {
>
>         $httpd_maxclients = 20
>         $php_error_reporting = "E_ALL"
>         $php_display_errors = ''on''
>         $envname = ''dev''
>         $envstr = ''dev''
>
>         include mywebserver
>
> }
>
> manifests/classes/mywebserver.pp would contain somethine like this:
>
> import "php"
> import "httpd"
>
> class mywebserver {
>
>         include centos # which would in turn include modules
''yum'' and
> ''resolv''
>
>         include httpd
>         include php
>         include php::apc
>
>         define httpd::vhost { ''mysite'' :
>                 servername      => "www.mysite.com",
>                 documentroot    => "/var/www/html/mysite.com",
>         }
>
> }
>
> modules/httpd/manifests/init.pp had:
>
> # defaults
> $httpd_maxclients = 150
> $httpd_...
>
> class httpd {
>
>         file { "/etc/httpd/conf/httpd.conf" :
>                 content =>
template("httpd/httpd.conf.default.erb"); # which would
> then use $httpd_maxclients
>         }
>
> }
>
> We also had a httpd::vhost($ip = "*", $port = 80, $servername,
> $documentroot, ...) define which would write VHosts files based on the
> following template:
>
> <VirtualHost <%= ip %>:<%= port%>>
>         ServerName      <%= servername %>
> <% if envstr != '''' -%>
>         ServerAlias     <%= envstr %><%= servername %>
> <% end -%>
>
> <% if envname != ''prod'' -%>
>         php_admin_value display_errors on
> <% end -%>
>
> ...
> </VirtualHost>
>
> modules/yum/manifests/init.pp had:
>
> # defaults
> $yum_base = "http://myrepo.myprivatenetwork.priv/centos"
>
> class yum {
>         yumrep { "os" :
>                 baseurl = "${yum_base}/RPMS.os",
>         }
>
> }
>
> modules/php/manifests/init.pp:
>
> php_memory_limit = "32M"
> php_error_reporting = "..."
> php_display_errors = "off"
> and so on ... (huge list)
>
> with php.ini.erb :
>
> display_errors = <%= php_display_errors %>
> error_reporting = <%= php_error_reporting %>
> ...
>
> And so on ... If you haven''t dozed off already, you get the idea.
:-)
>
> That way we could provide safe/sane default settings which could
> easily be tweaked on a per-host or per-class basis.
>
> Parameters were quite easy to track and were in the code (which is
> stored in SVN). There might be some scoping problems from time to
> time, I have to admit. But once we had our "pattern", things
would be
> smooth.
>
> I do now have trouble understanding how I should proceed with Puppet
> 2.6 (and 2.7 in the future), if I''m to avoid global variables.
>
> Parameterized class are seemingly not an option and, from what I
> understand and read, are more of an alternative to class inheritance

Parameterized classes are an attempt to solve the problem of feeding
data to classes.  They provide an alternative to global variables in
that sense, and especially they provide a more reliable and
predictable alternative to Puppet''s historic dynamic scoping
behavior.  In some cases they can be used instead of class
inheritance, too, but that''s not their main focus. Sadly, the current
implementation has enough design shortcomings that I recommend
avoiding it.  With luck, those issues will be resolved in the next
major release, "Telly".

> (Nigel Kersten''s comment on issue #13537): you don''t need
to inherit
> from a parent class if you want to tweak some of the ressources, you
> could just pass parameters to your class in the first place.
> Indeed I do not see how parameterized classes would help me get such
> flexibility. Or I''d have to "pass down" all the
variables I need from
> my node/host down to every class. Cumbersome, at best.
> Parameterized class a good for "coarse grained" tuning, but not
"per
> host" tweaks" on a variety of items.
>
> Next option is an External Node Classifier which I would have to
> develop and maintain to fetch/rewrite/generate/whatever variables I
> need. I could probably get what I want but I''d end up having an
extra
> tool to maintain (and train people to use).
>
> A "middle of the road" option would be Hiera and create a
hierarchy
> base on the ''$hostname'' fact (yaml backed for
''custom'' values, and
> probably a puppet backed to fetch the defaults ? I see that you can
> also pass a default value to hiera()) . I assume that''s the way to
go.

Another alternative would be to do exactly as you would have done with
0.24 or 0.25.  Global variables, node variables, and dynamic scoping
still work in 2.6, and even 2.7 (though 2.7 will issue warnings about
resolving variables via dynamic scoping).  As far as I know, global
variables will be supported in Telly, too, though you will have to
reference them by their fully-qualified names.

> Well... I''m a bit puzzled by all this. :-)
>
> I''d like some input from you guys (and gals !).
>
> I''ll try and install Hiera (nice, more stuff I need to package !)
> anyway. By the way what''s the target version (2.8 ?) for
Hiera''s
> integration into Puppet ?

Despite my comments about going the old-school route, I do think Hiera
is probably the most appropriate solution at this point.  I think you
will find that you can adapt your style pretty easily to use it
instead of global variables (or even simply to use it to set global
variables).

As I understand it, Hiera integration is targeted for Telly.  That may
or may not actually carry the version number ''2.8''.


John

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

Les Ault

2012-Apr-24 17:10 UTC

head link

Re: [Puppet Users] Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

On 04/24/2012 09:19 AM, Calimero wrote:> Hi,
>
> I worked with puppet (<  0.25) back in 2008/2009. We were able to
> deploy 200 servers from scratch and manage them. It worked fine.
>
> I''m now with a new customer and I''m pushing Puppet (and
I''m also back
> to puppet on a side project).
>
> We''re considering Puppet 2.6 to manage RHEL/CentOS 5 or 6 hosts.
I''m
> "upgrading myself" to Puppet 2.6''s new concepts and
features.
>
> Anyway consider this for the sake of argument:
>
> - node server1.hostingcompanyAlpha.com
> -- hosted on a dedicated server at provider Alpha
> -- production
>
> - node server2.hostingcompanyBeta.net
> -- hosted on a dedicated server at provider Beta
> -- production
>
> - node staging.myprivatenetwork.priv
> -- hosted on my customer''s private network
> -- staging/QA
>
> - node dev.myprivatenetwork.priv
> -- hosted on my customer''s private network
> -- development server
>
> Those four nodes must host the same elements:
> - Apache HTTPD with multiple VHosts
> - PHP
> - Extra software ...
>
>
> There are a few differences between nodes:
> - Servers don''t have the same capabilities (CPU/Mem/bandwidth): we
> need to tweak Apache''s MaxClients settings on a per-host basis
> - We need to tweak PHP : displaying errors on ''staging''
and ''dev'' but
> hiding them on server1/server2 (ie: setting
''display_errors'' to ''on''
> or ''off'' in php.ini)
> - On development and staging/testing servers we need to change some of
> the VHosts definitions: add extra serverAliases, etc ...
> - server1, server2 and staging/dev must use different DNS servers (/
> etc/resolv.conf) and RPM Mirrors (yumrepo{ })
>
> I''ve read the following blog post:
>
http://puppetlabs.com/blog/the-problem-with-separating-data-from-puppet-code/
>
> [snip ...]
I use facter variables to set dynamic parameters based on the host.  For 
example I created a module to modify sysctl entries:

node dbserver.example.com {
   include sysctl

   # Modify sysctl values
   $shmall = inline_template("<%= (memorysizeinbytes.to_i +
swapsizeinbytes.to_i) / 4096  %>")

   sysctl_entry { "kernel.shmall": value => $shmall, ensure =>
present }
}



-- 
*Les Ault* VCP, RHCE
Linux Systems Administrator, Office of Information Technology
Computing Systems Services

The University of Tennessee
135A3 Kingston Pike Building
2309 Kingston Pike
Knoxville, TN 37996
Phone: 865-974-1640

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

Ashley Penney

2012-Apr-24 17:54 UTC

head link

Re: [Puppet Users] Re: Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

It checks every layer of the hierarchy, so it would look for:

fqdn/server1.yaml
environment/staging.yaml
common.yaml

But the important thing to know is it''s looking for an actual variable.
If
you had defined
selinux: disabled in common.yaml and nowhere else then it would always
reach that
file and pull in that value.  Just because environment/staging.yaml matches
the state
of the machine doesn''t mean it''ll stop processing at that
point - it''ll
check every file
in the hierarchy it matches, in order, until it finds an entry for the
variable you are
looking up.  (In a manifest you do $var = hiera(variablename)).

On Tue, Apr 24, 2012 at 11:55 AM, Calimero
<calimero.ng@evolutive.org>wrote:
>
> That''s the part I don''t really get so far, as I
haven''t fiddled with
> Hiera yet.
>
> How would Hiera search through the hierarchy ?
>
> Try: fqdn/server1.yml
> ==> not found
> Try: environment/staging.yml
> ==> not found
> Fetch from common.yml
>
> Or:
> Try server1/staging.yml
> ==> not found
> Fetch from common.yml
>
> ie: is it "recursive" or it a list of "fallbacks" ?
>
>
-- 
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.

Calimero

2012-Apr-24 20:28 UTC

head link

[Puppet Users] Re: Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

On 24 avr, 19:10, Les Ault <au...@utk.edu> wrote:>
> I use facter variables to set dynamic parameters based on the host.  For
> example I created a module to modify sysctl entries:
>
> node dbserver.example.com {
>    include sysctl
>
>    # Modify sysctl values
>    $shmall = inline_template("<%= (memorysizeinbytes.to_i +
> swapsizeinbytes.to_i) / 4096  %>")
>
>    sysctl_entry { "kernel.shmall": value => $shmall, ensure
=> present }
>
> }
>
Calculation based on facts can indeed reduce the number of explicit
"per host" facts. But on the other hand you''re more or less
bound by a
single value.

I do have some "fact-based" dynamic settings, but usually on very low
level stuff (pathes depending of i386 vs x86_64, etc ...).

Thanks,
G

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

Calimero

2012-Apr-24 20:29 UTC

head link

[Puppet Users] Re: Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

On 24 avr, 19:54, Ashley Penney <apen...@gmail.com>
wrote:> It checks every layer of the hierarchy, so it would look for:
>
> fqdn/server1.yaml
> environment/staging.yaml
> common.yaml
>
> But the important thing to know is it''s looking for an actual
variable.  If
> you had defined
> selinux: disabled in common.yaml and nowhere else then it would always
> reach that
> file and pull in that value.  Just because environment/staging.yaml matches
> the state
> of the machine doesn''t mean it''ll stop processing at that
point - it''ll
> check every file
> in the hierarchy it matches, in order, until it finds an entry for the
> variable you are
> looking up.  (In a manifest you do $var = hiera(variablename)).
OK, search through the list until the value is found (unless you use
hiera_array which seems to grab all values).

Seems good to me.

Thanks !
G

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

Calimero

2012-May-18 16:23 UTC

head link

[Puppet Users] Re: Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

Hi,

On 24 avr, 18:40, jcbollinger <John.Bollin...@stJude.org> wrote:
> Another alternative would be to do exactly as you would have done with
> 0.24 or 0.25.  Global variables, node variables, and dynamic scoping
> still work in 2.6, and even 2.7 (though 2.7 will issue warnings about
> resolving variables via dynamic scoping).  As far as I know, global
> variables will be supported in Telly, too, though you will have to
> reference them by their fully-qualified names.
>
I''m back at fiddling with globals or hiera. Not sure yet which way
we''ll go but while playing around, I''ve have some unexpected
results.

manifests/site.pp:

$globalenv = "prod"

node    ''centos6.priv.net'' {
        $globalenv      = "int"
        class { "yum" :
        }
}


modules/yum/manifests/init.pp
class   yum::params {
        notify { "yum-params" :
                message => "yum:params globalenv$globalenv /
::globalenv=$::globalenv"
        }

        $baseurl = $globalenv ? {
                        ''int''   =>
''http://testing.priv.net'',
                        default =>
''http://production.priv.net'',
                }
}

class   yum(
        $baseurl        = $yum::params::baseurl,
        $centosversion  = "current"
        ) inherits yum::params {



I''m mixing the the "sane parameter default" pattern with
global
variables. We''ll see whether that leads to something useful but my
issue right know is that $globalenv and $::globalenv do not evaluate
to the same value.

Here''s what Notify[yum-params] displays:
notice: /Stage[main]/Yum::Params/Notify[yum-params]/message:
current_value absent, should be yum:params
globalenv=int / ::globalenv=prod (noop)

It seems $::globalenv evaluates to the top-level scope/value while
$globalenv returns the "overridden" value. Is that the expected
behavior ? Am I missing something ?

I''m running puppet 2.6.16.

Thanks !
G

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

jcbollinger

2012-May-18 19:35 UTC

head link

[Puppet Users] Re: Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

On May 18, 11:23 am, Calimero <calimero...@evolutive.org>
wrote:> manifests/site.pp:
>
> $globalenv = "prod"
>
> node    ''centos6.priv.net'' {
>         $globalenv      = "int"
>         class { "yum" :
>         }
>
> }
>
> modules/yum/manifests/init.pp
> class   yum::params {
>         notify { "yum-params" :
>                 message => "yum:params globalenv> $globalenv /
::globalenv=$::globalenv"
>         }
> [...]
> }
> [...]
> Here''s what Notify[yum-params] displays:
> notice: /Stage[main]/Yum::Params/Notify[yum-params]/message:
> current_value absent, should be yum:params
> globalenv=int / ::globalenv=prod (noop)
>
> It seems $::globalenv evaluates to the top-level scope/value while
> $globalenv returns the "overridden" value. Is that the expected
> behavior ? Am I missing something ?
That is exactly the expected behavior in Puppet 2.7.x and earlier.  It
is an example of Puppet''s dynamic scoping behavior.

Resolving variables from dynamic scope is deprecated in 2.7, however,
and dynamic scoping will be removed altogether in Telly.  A v2.7
master would emit a deprecation warning about your reference to
(unqualified) $globalenv where it is not lexically in-scope.

Importantly, do note that node variables are NOT globals.  Also, node
variables do not have qualified names, so the deprecation and eventual
removal of dynamic scoping significantly limits their usefulness.


John

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

Apparently Analagous Threads

Search for more seemingly similar threads

Puppet users - Apr 2012 - Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

[Puppet Users] Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

Re: [Puppet Users] Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

[Puppet Users] Re: Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

[Puppet Users] Re: Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

Re: [Puppet Users] Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

Re: [Puppet Users] Re: Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

[Puppet Users] Re: Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

[Puppet Users] Re: Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

[Puppet Users] Re: Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

[Puppet Users] Re: Moving from Puppet 0.25 to Puppet 2.6+ : global scope/variables

Apparently Analagous Threads