Hi,
Using External nodes parameters solved similar problem for us.
Cheers,
Ohad
On Tue, Nov 18, 2008 at 2:48 AM, Luke Kanies <[EMAIL PROTECTED]> wrote:
>
> 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 [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
-~----------~----~----~----~------~----~------~--~---
