Hi All, I hope this ends up in the right place, as I haven’t tried posting to the list in this way before. In any case, Michael DeHaan recently proffered this advice:
> > Does anyone know how to achieve the above in a "prettier" fashion? > > Thinking about it some more... > > Create a baseclass called "exim" and subclasses called "exim:web" and > "exim:smtp" > > Have the class "webserver" include exim:web and the class "smtpserver" > include "exim:smtp". Although that likely could be made to work, it seems needlessly brittle to me. Each subclass must be careful to not override the base class in a way that is incompatible with the other subclass, lest nodes that include both subclasses break. The door is open for such breakage to occur with a manifest update at any point in the future, and the nature of the issue makes it a greater than average risk to slip through QA. In general, I think Puppet subclassing should be avoided wherever it does not provide a substantial win over the alternatives. If one of the alternatives is including a class instead of extending that class, then including is usually better. In particular, if a subclass does not override its base class in some way, then it can and should be rewritten to include the erstwhile base class instead of extending it. As described above, moreover, it is risky for any node to include two descendents of the same class, therefore any inheritance tree where siblings are not mutually exclusive should be refactored. Good manifest design reaps great rewards in maintainability and future development. Regards, John Email Disclaimer: www.stjude.org/emaildisclaimer -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
