On Mar 21, 4:56 am, Guillaume Rousse <guillomovi...@gmail.com> wrote: > Le 18/03/2011 19:15, jcbollinger a crit :> If you have many nodes with > various small differences between them, > > then perhaps it's time to look into an external node classifier. > > If I'm understand correctly, this just move the problem elsewhere > (potentially making it easier to solve), as the classifier will have to > manage parameters overriding itself.
I prefer to characterize the possible move to an external node classifier as redefining the problem. Rather than solving "how do I override the parameters of a parameterized class", we can instead focus on the higher-level problem "how do I assign the correct parameters to my nodes' classes?" The external node classifier would indeed need to choose the correct parameters for each parameterized class it assigns to each node, but that does not necessarily involve any form of overriding. This approach is one of those that makes sense when no single hierarchy is sufficient to characterize your nodes. If an external node classifier is undesirable (which it may be for any of several reasons), then some of these suggestions may help: 1. Flatten the node hierarchy. The deeper the hierarchy, the more likely it is that you will end up with a node that wants to be at two different places in it. 2. Make classes self-contained as much as possible. In particular, do not use parameters to pass information that classes can determine for themselves based on the available facts. 3. Don't hesitate to make your classes smart, so that they adapt resource declarations appropriately for your nodes. 4. Where possible, refactor common logic into ordinary classes that multiple other classes and/or nodes can include, rather than into node definitions. This is a viable substitute for many of the uses to which parameterized classes are put, but beware of variable scoping issues that may arise. It's safest to rely only on facts. 5. Prefer to assign the correct classes to each node in the first place, rather than relying on overriding. On the other hand, DO override resource properties (by including subclasses) where it makes sense to do so. 6. Make sure your classes have well-defined scope and purpose, even if this means you end up with many small classes. 7. Consider extlookup() John -- 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.
