On Mar 21, 7:10 am, Guillaume Rousse <[email protected]> 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/[email protected]/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 [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-users?hl=en.
