On Jun 23, 9:54 am, Nigel Kersten <[email protected]> wrote: > On Thu, Jun 23, 2011 at 6:01 AM, jcbollinger <[email protected]>wrote: > > > > > While I'm on my soapbox, this is one reason why I don't like > > interclass dependencies very much, and why run stages (which magnify > > this problem) need to be approached with caution. There is certainly > > something to be said for the layer of abstraction achieved by relying > > on interclass dependencies instead of on finer-grained inter-resource > > dependencies, but you can't do it halfway. > > I agree with the halfway bit :) but generally I feel that class-to-class > relationships are much easier to maintain than resource-to-resource > relationships that cross class boundaries. > > It allows you to change the internal relationships and behavior of classes > without worrying so much about external consumers of your class. > Encapsulation is a good thing.
I quite agree that encapsulation is a good thing, but it is impractical to expect rigorous encapsulation in Puppet's problem domain. System configuration does not break up neatly along any hierarchical lines I have ever considered, so there are many non- trivial questions of which class should own which resource, and of how non-owning classes can express their own requirements. The OP's problem is evidently an example. Furthermore, remember that Puppet resources all have global scope, regardless of where they are declared, so Puppet classes and modules provide rather incomplete encapsulation anyway. Their greatest usefulness is instead in the layer(s) of *abstraction* they embody. Right now, the main advantages of prefering resource-level relationships are a lower likelihood of dependency cycles, and a clearer path to resolving any that arise. As Puppet development continues, however, avoiding unnecessary relationships among resources could conceivably facilitate useful optimizations, such as combined application of multiple Package resources. Though presently Puppet itself may not do much with it, in general, the more freedom one can afford to an expert system, the better. > Your modules are significantly less reusable if you need to document > required individual resource relationships. Given that Puppet permits resources to be managed only in one place, reusable modules need to thoroughly document all the resources they manage anyway, or at least to document an exclusive claim to an appropriate swath of resources. How reusable you can hope a module will be depends greatly on how diverse the demands are on the resources it manages. Cheers, 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.
