Luke Kanies:
> Also, to be clear, I *wholly* encourage this kind of discussion and
> recommendation. I've never claimed I have the ultimate vision of
> Puppet's language, and I'm always looking for recommendations to make
> it better. Of course, I will always defend the existing syntax, and I
> will always fight to keep the basic vision I have intact.
Well, one thing I came across that really hinders efficient
configuration management with puppet at my current employer is the
structure of servers and services we have is the write-once variables
thing in puppet. I know this is not directly tied with the
definition/class differentiation, but at least one issue raised in the
thread reminded me of this problem: The use of (not always completely)
global variables in recipes.
To be a bit more specific, we came across this limit three times
already, while still doing the basic system config (not yet any services
besides Kerberos/LDAP), which boil down to puppet not being able to do
this as a programmer would expect:
node base {
$dom="example.local"
include hostsetup
}
node public_server inherits base {
$dom="example.org"
}
node internal_server inherits base {
include ldap
}
....
node mx inherits public_server {
include mailsetup
}
node special_node inherits public_server {
$dom="example.com"
}
(all but the last being templates for use by actual host definitions,
where "class hostsetup" somehow uses $dom)
In other words, overriding some variables in a derived node (or class
for that matter) where the types/templates used in the ancestor actually
access the most specific variable declaration (youngest generation
derived node/class that declares the variable). In the example above,
for node mx, the class nodesetup should see $dom being "example.org"
while for node "special_node", it should see "example.com".
I know there are workarounds for the write-once problem, but they all
add complexity to the manifests.
Actually, what would be even better would be to have multiple
inheritance (but the workaround for this is much smaller in our case),
so that it would be easy to set up templates for
mx[12].dc[12].example.org
db[12].dc[12].example.org
web[12].dc[12].example.org
(i.e. having two (or more) different subdomains, with both having
multiple instances of each server type. Currently, we define the server
types in classes while defining the domain structure in initial node
templates, then combining them into node templates for each
subdomain/server type combination, which are then inherited by the
individual nodes.
Any suggestion for a more elegant solution would be appreciated.
regard,
Sven
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
