I am going to use parameterized class together with extlookup, where extlookup is used to provide different parameter value for different node based on extlookup_precedence, the parameterized class needs to be declared once in parent node, any issues you could forsee with this plan?
- Hai On Mon, Mar 21, 2011 at 9:47 AM, jcbollinger <john.bollin...@stjude.org>wrote: > > On Mar 21, 7:10 am, Guillaume Rousse <guillomovi...@gmail.com> wrote: > > Le 21/03/2011 10:56, Guillaume Rousse a crit :> 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 just found a potential answer in list archive: > http://www.mail-archive.com/puppet-users@googlegroups.com/msg11122.html > > > > The subtility is not to call the defined resource a second time, but to > > refers to it: > > Broken["message"] { value => "not " } > > instead of > > broken ( "message": value => "not" } } > > Yes, this is resource overriding, which I mentioned earlier. It can > be done only in a subclass of the class containing the definition of > the resource in question. Inasmuch as the OP remarked that they > wanted to avoid subclasses, I think they are aware of this option and > find it unsuitable. > > > I just tried the same example with parameterized classes, it doesn't > work: > > > > node default { class { message: value => "" } } > > node "beria" inherits "default" { Class[message] { value => "not " } } > > class message($value) { notice("This is ${value}broken") } > > > > So, defined type seems still more flexible than parameterized classes. > > > Parameterized classes are not resources any more than ordinary classes > are, syntax similarity notwithstanding. You cannot override the > parameters of a parameterized class. > > Defined types are effectively custom resource types written in the > Puppet DSL instead of in Ruby. Resources of such types behave like > resources of any built-in or custom type, so among other things, their > parameters can be overridden via subclasses. > > I don't think it's fair to say that defined types are more flexible > than parameterized classes, because the two features aren't on the > same level. On the other hand, I think that parameterized classes do > receive more attention than they deserve. They solve certain > problems, but they also have limitations that plain classes do not > have. In particular, ordinary classes' idempotency and support for > multiple inclusion constitute a very powerful Puppet feature that > parameterized classes cannot (currently) provide. > > I would not recommend anyone to use parameterized classes without > understanding exactly why they are doing so and what it may cost > them. If the benefit justifies the cost, however, then go for it! > > > 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. > > -- 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.
