On Tuesday, March 4, 2014 9:56:33 AM UTC-6, Jose Luis Ledesma wrote: > > > > > On Tue, Mar 4, 2014 at 3:36 PM, jcbollinger > <[email protected]<javascript:> > > wrote: > >> >> >> On Tuesday, March 4, 2014 1:30:44 AM UTC-6, Jose Luis Ledesma wrote: >>> >>> Although it is not incorrect, you should not bypass class boundaries, so >>> it's better: >>> >>> require=>Class['munin::install'] >>> >> >> Well, that's one school of thought. Personally, I don't have any problem >> with cross-class relationships within the same module, as the OP's appears >> to be. In fact, I'd be willing to accept any cross-class relationship at >> all, provided that the class and module of the relationship target >> *document* the target as being declared by the module and available for >> such use. (But no one does that.) >> >> >> > > Perhaps it is, but I found it very useful when in the install class > you have to install more than one package, if you set up the require > against the install Class you don't have to care anymore about it. > >
That's in no way inconsistent with what I said. The central issues here for me are 1. using an appropriate level of precision in your declarations, and 2. public *vs*. private characteristics of modules. Using an "appropriate" level of precision does not necessarily mean the issuing the narrowest and most precise relationship declarations possible. You can be too specific, thereby making your manifest set brittle and making its maintenance more costly. You can also be too general, however, thereby increasing your exposure to relationship cycles and making Puppet work harder to order resources. How, then, should one find the best balance? That's where the public vs. private distinction enters the picture. Puppet DSL does not enforce any encapsulation, but I consider it a best practice to consider undocumented features of a module to be private to that module, whereas documented features are public (unless the documentation specifically says otherwise). If the module author makes a module feature -- a class, a definition, a declared resource, a variable -- public by documenting it then he is making a commitment to keeping that feature present and consistent with the documentation, and also to document when the feature nevertheless is changed or removed. Therefore, relying only on public module features minimizes maintenance risk. Among public features of a module, however, one should choose the most specific relationship targets consistent with the purpose of the relationship. If one really cares only about a specific Package, say, whose declaration is a public module feature, then that's where one should point their relationship. If what one really wants, on the other hand, is "all the packages required for Foo to work" then it is probably more appropriate to point your relationship at some class. The same logic applies inside a module, but although it seems common in the community to take the Puppet class as a subunit of modularity, I think that's mainly another unwarranted holdover from OO-think. Individual classes in a multi-class Puppet module are rarely independent units in the sense that applies to well-designed classes in an OO programming language. In Puppet, that level of unity typically applies only to modules. Thus, within one module I consider all classes and resources fair game for relationships. That doesn't mean that in any given case it's necessarily a good idea to point a relationship at a resource declared by a different class in the same module, but sometimes that is the best thing to do. A flat rule against doing so is needlessly restrictive. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/63418eee-604c-468c-a680-65138be280a4%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
