On Monday, December 2, 2019 at 1:56:32 PM UTC-6, Abhijeet Rastogi wrote: > > Hi Ramin, > > Thanks for the details and the link. That was indeed the cause of this > issue. > > I wonder what official puppet guidelines are for managing this sort of > inter-module dependencies. I couldn't find a guideline on official docs. > https://puppet.com/docs/puppet/latest/lang_relationships.html > > Module compatibility and inter-module dependencies have always been tricky issues with Puppet. I am unaware of any guidelines on the topic from Puppet, Inc., and I'm not too surprised about that because there are a lot of situation-dependent details. To a large extent, however, the onus is on module authors to make their modules play well with others. If you have to work with modules that present interoperability problems then you pretty much have to figure it out on a case-by-case basis.
As far as writing your own modules to be maximally interoperable, there's a bit of art and a bit of science. You'll find suggestions and discussions of that topic in the archives of this group, among other places. Here are some off-the-cuff suggestions: - Provide a very small number of module interfaces. Oftentimes, just one is ideal. An "interface" in this sense is a front-end class or a defined type that is intended to be declared by code outside the module. - Such public classes should exercise proper containment of any private module classes they declare. - All module classes should express appropriate ordering of external classes they declare, which typically is one or more "require" or "before" relationships instead of full containment. Do not over constrain ordering, however, as that can be as bad as or even worse than under-constraining it. - Modules should maintain a tight focus, so as to minimize the risk that two modules serving different purposes attempt to manage the same resource. - Where there is a potential or actual resource-management collision, the best solution is usually to factor the affected resource out into its own module, but it is sometimes more practical to use class parameters to control which module has responsibility for managing the resource. - Overall, module designers and implementers must bear ordering requirements in mind as they work, not only as they affect the module itself, but also as they relate to the module's interactions with others. - Write good documentation. What does the module manage? What are its public interfaces? What do its class parameters signify, what are their allowed values, what are their defaults (if any)? What other modules does it use, and how? 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/1a14a612-226a-4569-be47-8e5180d607fe%40googlegroups.com.
