On Tuesday, June 18, 2013 11:16:15 AM UTC+2, Matthias Saou wrote: > > On Mon, 17 Jun 2013 07:32:36 -0700 (PDT) > Alessandro Franceschi <a...@lab42.it <javascript:>> wrote: > > > Thanks for your opinion, even if I don't fully agree with it. > > Puppet is a language and so people do the same things in different > > ways, and they all work and do what they are supposed to do. > > But if we think about modules REUSABILITY and INTEROPERABILITY some > > patterns have to be followed. > > Some of the parameters described in the document are somehow > > REQUIRED, IMHO, if you want to make a really reusable module (for > > example the ones that let you decide how to manage your configuration > > files... if you enforce a logic in a module or a specific template > > and don't allow override by users, then you are not making a reusable > > module, so for example a parameter like "template" is just needed). > > So, since, at least some of, these parameters are needed for a > > reusable module it's just a matter of defining few naming > > conventions (and managing external modules dependencies in a sane > > way) to make different modules happily live better together. > > > > Note, I don't say that ALL the modules should have ALL these > > parameters, I'd consider these Standard Namings as suggestions which > > people may decide to follow or not (somehow similar to the Code Style > > suggestions, which leverage the style of the Puppet code and have > > found tools like puppet-lint to validate them). Once enough good and > > prominent Puppet modules will follow these naming conventions, it > > will be easier for people to switch modules, integrate the best ones > > from different sources (without forking them) , use these parameters > > from a WEB interface, a a standard framework from smoke testing and > > have the benefits which are better described in the blog post. > > > > Note also that these proposals are based on the current Puppet > > language specifications, I want to start from what can be used now, > > with an eye on the evolution on Puppet, but with still feet on the > > ground: nothing new or to invent, just few basic naming convention to > > agree upon and *suggest*. > > > > I still think that this is at hands reach :-) > > This is definitely a good initiative, what I'm just saying is that > you've opened a can of worms :-) >
Lol, we have to do that sooner or later, I think :-D And the sooner, the better. > > The initial step of creating common guidelines for parameter names is > nice, as it can create some consistency across modules, and ease work > sharing as well as lower the learning curve for people using 3rd party > modules. But it would need to be official (in the puppet documentation > as best practices, for instance) and/or enforced on the forge, to > become really useful. > I definitively agree. This is something that should be endorsed if not managed directly by PuppetLabs. Anyway I would not "enforce" the use of standard params, but somehow "certify" the modules that provide them (eventually defining different "levels" of standard params coverage) so that you know you can use them with established patterns (and in the future maybe test them with standard procedures and integrate them in an ENC that explicitly supports and exposes these standard parameters) > > And after that, things quickly get exponentially complex IMHO. A few > examples from the top of my head : > > * Naming the modules themselves. > Right, even if, besides few cases with somehow flurry namings (apache or httpd? ssh or openssh?), generally the name of the module is already quite standard. > * Naming the classes and definitions inside the modules. > * Multiple modules requiring the same packages (If my module needs > rsync, yours too, where do we put the common virtual resource?). > This is a wide and tricky issue. My naif approach is the definition of a dependency_class parameter where external resources like rsync are managed (and you can provide a custom dependency_class where you manage the required resources in the way you want). For the installation of simple packages I'd currently use/recommend the not perfect "if ! defined" approach (always in the dependency_class). When the language will provide a smarter solution, we can follow it, some past discussion on possible solutions there has been in the list, in order to work they definitively have to be shared by the modules (so they fit well in the "standard module" pattern). Some of them required enhancements to the DSL some not, being a Puppet user I prefer to stick to current language syntax. > * The use of author-specific common modules (I don't like taking a > johndoe/apache module and noticing I then need johndoe/common). > I'd try to leverage modules on stdlib as much as possible, but at the same time some "local common" modules are sometimes needed. It doesn't harm to have them in your modulepath, as long as there are no naming conflicts. > > But don't get me wrong, I like where this is headed, and will > participate as much as I can. > Cool. Actually I found your proposals on the service management parameters, on the Google Doc draft, quite sane , so keep on! Al -- 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 post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users. For more options, visit https://groups.google.com/groups/opt_out.
