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

[Calimero]

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.

[Ashley Penney]

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.

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

[Calimero]

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.

[jcbollinger]

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

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

[Les Ault]

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

[Ashley Penney]

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

[Calimero]

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

[Calimero]

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

[Calimero]

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

[jcbollinger]

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