On Friday, June 20, 2014 8:01:49 PM UTC+2, Trevor Vaughan wrote: > > +1 to everything that John has said. > > While many Forge modules are not useful to me out of the box, I have had > good luck modifying them to meet my needs at any given time. >
Well, in my very personal opinion, if someone takes a module of mine and has to modify it in order to make it meet his needs, I've lost. I think, as a general rule, that every Puppet setup should have at least 2 separated directories in the modulepath. A shared, common, one, with public modules downloaded from the Forge or other sources, and not modified. A site, local, one, with local modules and eventually the public modules that have been downloaded and changed (the less of these, the better) for local needs. > I've also been able to learn new ways of doing things (and not doing > things) due to the willingness of people to share. > > I do think that some of the recent proposals around allowing multiple > modules that cover the same material to exist on the same system are a good > thing and could help with reusability in the future. In this case, you > would get chunks of reusability that work together but that happily coexist > with other isolated chunks. > Are you referring to these? https://groups.google.com/forum/#!topic/puppet-dev/em-WGLCrdIw https://groups.google.com/forum/#!topic/puppet-dev/dkdXaUt8yDg > It's good to have these types of discussions though. Knowing different > users' ideas of perfection can encourage different automated methods of > attempting to attain perfection in the future (puppet-lint for example). > Indeed, and actually this was the reasoning behind this post, as sometimes I wonder how some things I consider obvious or necessary really matter and are considered useful by others. I generally try to figure out solutions following the current status of the Puppet language (I consider myself an end user) also considering the inevitable lapse of time that occurs from a feature development to its usage at large. Still, proposals as the ones expressed in the linked threads are definitively worth attention, thanks Al > > On Fri, Jun 20, 2014 at 11:04 AM, jcbollinger <john.bo...@stjude.org > <javascript:>> wrote: > >> >> >> On Thursday, June 19, 2014 11:09:22 AM UTC-5, Alessandro Franceschi wrote: >>> >>> Hi all, >>> I've written a blog post with my opinions on the current modules >>> ecosystem: >>> http://www.example42.com/2014/05/31/rethinking-modules-part-1/ >>> >>> The post talks about : >>> What are the reusability features a module should have, imho >>> The distinction between application (component) modules and higher >>> abstraction modules >>> What are the challenges and reusability options for higher abstraction >>> modules >>> >>> It also raises a pair of points of the challenges that, according to me, >>> we should face in our future modules: >>> Patterns to extend reusability of higher abstraction layer modules >>> Standardisation in the component application modules >>> >>> I'm truly interested in hearing others' opinions on these topics, in >>> order to understand if such points are important only for me or they >>> reflect common concerns. >>> >>> >> >> I have never accepted the premise that "reusable" as applied to Puppet >> modules has to mean "usable in any context, to achieve any end related to >> the module's area of application, via any conceivable style," which is >> pretty much how I read your reusability criteria for component modules. >> Certainly a module that satisfies those criteria can serve pretty much any >> purpose within its domain, but what matters to me at any given time is >> whether a module can serve *my* purpose, whatever that happens to be. >> >> If some third-party modules are (re)usable for me but not for (say) >> Felix, and vise versa, then that doesn't change the fact that both our jobs >> are made easier by not having to write everything from scratch. If that >> means I need to study a module a bit before I decide whether to use it, >> then fine -- I ought to do that anyway. >> >> Moreover, I think it is harmful to the module ecosystem to promote a >> position that only Cadillac modules are "reusable," because that sets the >> bar very high for potential contributors. I don't think it helps anyone to >> tell people that their contributions are unwelcome (which branding them >> "not reusable" does). Most people who write modules do so for their own >> purposes first and foremost, and if the community is unwelcoming to them >> then they will just keep their work to themselves. >> >> >> I agree, however, that there is a useful distinction between "component >> modules" and higher-level modules, and also that some higher-level modules >> are conceivably reusable. I furthermore agree that the criteria you set >> out all tend to make such a higher-level module either applicable to more >> use cases or easier to integrate. >> >> On the other hand, I tend to think that higher-level modules will less >> frequently be used together on the same nodes than are component modules, >> so that integration considerations are less of an issue. I also tend to >> think that reusable higher-level modules will be fewer than component >> modules, so that standardization is less of a consideration for them. Of >> course, I think I ascribe less importance overall to standardization (of >> Puppet modules) than you do. >> >> >> I have recently decided, too, that more of the responsibility for module >> reusability has been placed on module authors than is needful or useful. >> Puppet itself could and should provide more support than it does. In >> particular, I would like to see more flexible data binding (e.g. a >> mechanism for data aliases and/or indirect data names, a mechanism for >> slicing data, improved DSL-based data injection, etc.), and more flexible >> class / module resolution (e.g. aliases / indirection). These sorts of >> features would improve *all* modules' reusability by opening more >> flexible approaches to integrating modules into a site's manifest set. >> >> >> 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...@googlegroups.com <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/puppet-users/e30a76b9-3f1a-4408-8cc4-d4c2a2207874%40googlegroups.com >> >> <https://groups.google.com/d/msgid/puppet-users/e30a76b9-3f1a-4408-8cc4-d4c2a2207874%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Trevor Vaughan > Vice President, Onyx Point, Inc > (410) 541-6699 > tvau...@onyxpoint.com <javascript:> > > -- This account not approved for unencrypted proprietary information -- > -- 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/1c9e8439-08bb-4906-97ad-654e5923a916%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
