On Nov 17, 2008, at 9:55 AM, Sven Mueller wrote:
>
> 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)
This is a common problem I haven't been able to find a good solution
for. It's not so much related to the write-once aspect of variables
as it is related to the fact that classes are evaluated immediately,
so the subnode's overriding of a variable has no affect.
>
> 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.
An external node solution would work much better.
--
The real art of conversation is not only to say the right thing at the
right place but to leave unsaid the wrong thing at the tempting
moment. -- Dorothy Nevill
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
