Well, it is not an unbreakable rule, but from my point referencing individual resources from another class is a source of possible future problems.
In a simple module like the OP seems to expose, that is: Params Config Install Service If you reference individual resources from another class will probably mean: 1. Make it difficult to read/understand for other people 2. Implenting this module for another Linux flavour will be harder (package/service name changes and so on) 3. Modifying it to add some other package/service/configuration will be harder too. Point 2 and 3 also means possible undesired behaviors. Just my point of view... P.n. it is really a pleasure read all of your posts El 05/03/2014 15:49, "jcbollinger" <[email protected]> escribió: > > > 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]>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<https://groups.google.com/d/msgid/puppet-users/63418eee-604c-468c-a680-65138be280a4%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/groups/opt_out. > -- 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/CAF_B3dchm6e%3DPGxMTwRePO5zgBxRZPfgsXb7goHVFxxZOV2Rug%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
