> Long yes, but it did help define your issue. I think the first layout > would be a more correct one, and from my experience should work, I > think. Have you tried doing zones::global and zones::nyc as inherits? > When you then redefine the variables in the node definition they > should override the settings in the inheritance. Inheritance puts > things in the parent scope and includes puts variables in the child > scope I thought variables you inherited would already be set and thus unchangeable. I'm testing this now but it seems to work. Thanks for the insight.
All the docs I've seen suggest using node inheritance to manage "roles" but it seems to me that we should be using classes to manage roles and inheritance to handle variables. It's not as clean because you can't see at a glance what variables a node is inheriting (because you can only inherit one other node and thus have to build a node tree- but at least this seems to work. I'm going to go test this now and see if I can get it to do everything I want. It definitely looks like progress. > > 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. > This type of situation where you have the same thing defined across > several nodes is in theory best handled by virtual resources. I have > encountered similar issues and that is the advice I got. I am still > working on making that change so am not sure who much use my > explaining virtual resources will be. Virtual resources could work, but it seems overly complex for what i'm trying to do. It's not so much that I'm trying to define the same object across multiple resources, but more a specific variable. Having to create a virtual resource and then instantiate it every time I add a new ACL seems to be a lot more trouble than just setting my ACL variable appropriately. > As a general thought, looking at the complexity you have, are you > using external node definitions? From what I have read on the list and > about you site that looks like it would be extremely useful to you and > possible something using stored configs could help resolve your > issues. I already run LDAP but haven't moved my nodes into it yet. I don't want to go to all that trouble until I'm sure I can resolve some of these hierarchy issues. Just moving the values into ldap won't help unless I start writing all sort of functions in puppet to query resources and configure them appropriately. Again- that's way more trouble than I'm willing to deal with. At that point I might as well invest the time and effort to learn Chef as it seems to have native support for overrides. I just wish I knew why puppet was designed in the way it was sometimes. Scoping makes sense in a lot of languages, but here it just seems to get in the way. Ditto for the declarative nature of the language. -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 -~----------~----~----~----~------~----~------~--~---
