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

Search Discussions

  • Ashley Penney at Apr 24, 2012 at 1:34 pm
    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 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 at Apr 24, 2012 at 3:55 pm

    On 24 avr, 15:34, Ashley Penney 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.
  • Ashley Penney at Apr 24, 2012 at 5:54 pm
    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 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 at Apr 24, 2012 at 8:29 pm

    On 24 avr, 19:54, Ashley Penney 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.
  • Jcbollinger at Apr 24, 2012 at 4:40 pm

    On Apr 24, 8: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-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.
  • Calimero at May 18, 2012 at 4:23 pm
    Hi,
    On 24 avr, 18:40, jcbollinger 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 at May 18, 2012 at 7:35 pm

    On May 18, 11:23 am, Calimero 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.
  • Les Ault at Apr 24, 2012 at 5:11 pm

    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.
  • Calimero at Apr 24, 2012 at 8:28 pm

    On 24 avr, 19:10, Les Ault 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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedApr 24, '12 at 1:20p
activeMay 18, '12 at 7:35p
posts10
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase