> Here I am seeing a thought process barrier. You do not have to tye a
> template case to _servers_ by name. The idea is to tye the template
> case to _roles_.
Great- I have a "role" called NTP master. The NTP master in datacenter
A uses a different stratum 1 clock than the master in Datacenter B.
The NTP client in office A uses different masters than clients in
office B. Building a hundred cases into my template file to cover all
the variations is completely unmanageable. I want to be able to set
defaults for certain zones and then be able to override them. Puppet
seems to be _completely_ against that philosophy.
I also do not like the idea of mixing a module definition (which
covers things like required packages and services) with specific
settings like server names (even if the server name is part of a case
statement in the template). My templates are all _completely_ generic.
I can use them in any site by altering the variables I pass in.
(I have used $ldap_server as a variable to determine whether or not to
include the slapd.conf and openldap-servers packages- but that doesn't
obviate the need to be able to set values for the variables I need to
pass into the templates).
> That way it does not matter what the server name is
> or where it is. If it is defined as have having a ntp server role then
> it gets that configuration.
Of course it matters where the server is. Different sites have
different reference clocks, different masters, different ACL's.
The "role" is fine for defining what packages to include,
I need "zones" which allow me to specify default settings for the
packages in those roles! Without that I either need to split my
specific settings up into dozens of modules and try to manage them
that way (which is silly given that there is bound to be overlap
between settings and one of the first rules of normalization is to
avoid duplication) or establish a completely flat node hierarchy which
will also include lots of duplication.
> One of the strengths I have found in
> templates is that you can but the logic in the template.
This means that to change something like an ACL, which might be the
same across several different services, you now need to change it in
several templates, or several node definitions. That can not be
considered a good way to do things.
I feel like the right way to do this is simple:
I define zones (or sites or environments or whatever). Each has
certain values set and subsequent includes override previous ones.
For example:
class zone::global {
$ldap_base = "dc=example,dc=com"
$ldap_servers = ['ldap01.example.com', 'ldap02.example.com']
$ntp_servers = ['ntp01.example.com',
'ntp02.example.com']
$ntp_acls = ['']
$my_domain = "example.com"
}
class zones::nyc {
$ldap_base = "dc=nyc,dc=example,dc=com"
$ldap_servers = ['ldap01.nyc.example.com', 'ldap02.nyc.example.com']
$my_domain = "nyc.example.com"
}
class: roles::general {
include ldap
include ntp
include resolver
}
class roles::ldapserver {
$ldap_server = true
include roles::webserver
}
node www02.example.com {
$ldap_servers = ['ldaptest1.nyc.example.com',
'ldaptest2.example.com']
include zones::global
include roles::general
include roles::webserver
}
node host1.nyc.example.com {
$ldap_servertype = "slave"
include zones::global
include zones::nyc
include roles::general
include roles::ldapserver
}
In the last node example I defined roles::ldapserver. That role
specifies the packages to be installed for an ldap server, as well as
the server type. It still includes the ldap base ldap module, but with
some additional packages and possibly with some additional default
values passed in.
That allows me to keep all my settings (roles, zones, etc.) in /etc/
puppet/manifests and my modules in /etc/puppet/modules thus preserving
a division between settings and implementation.
It also lets me see, at a glance, what I am including and what I'm
excluding. I don't need to look into a specific module template to see
what settings may or may not be enabled. It's right there in the
manifests directory where I am already working. It also means I can
share modules much more easily.
Am I nuts in thinking that this is a better organizational style? The
puppet books talks about workarounds for some of these problems.
Should we be working around these issues or do they need to be
"fixed"?
Perhaps there is a serious implication for the language that I've
completely missed- if so- please let me know.
-Don
--~--~---------~--~----~------------~-------~--~----~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
