On Monday, July 1, 2013 5:21:44 AM UTC+2, Ryan Coleman wrote: > > Hi Al, et al. I apologize for being so late to this party but I'm loving > all the conversation around this. I've read through the Google Doc and > found lots of cool ideas on class parameter names. Please forgive me > though, my product manager wired brain wants to pause at this point and > discuss it a bit first before I offer my opinions on the doc. > On Tue, Jun 18, 2013 at 11:19 AM, Alessandro Franceschi <a...@lab42.it<javascript:> > > wrote: > >> For me a module is reusable when: >> 1- It supports many different OS (this is somehow implicit and does not >> involve naming conventions) >> 2- It leaves to the user freedom on how to populate and customize the >> provided configuration files ( I think this is the main point for most >> reusability cases) >> 3- It allows the user to manage some behaviours of the module (has a >> service to be restarted after a file change? Do I want to manage a service >> status (at runtime or boot) >> 4- In (somehow extreme) cases it allows the user to customize names of >> package/services, paths of files and so on >> 5- It allows seamless addition of custom resources, not managed by the >> module but related to it >> 6- It allows the user to decide where to place his data (also this is >> out of naming convention scope) >> > > I'll admit that this is my Forge biased view of things, but I'm working > towards modules that are reusable, interoperable and introspectable. It > would help me contribute to the discussion if we could hammer out whether > we loosely agree on the goal and definitions. I'm already pretty happy with > your definition of reusable, but I'll paraphrase. > > > Interoperable > > - Module A is known to do X, Y & Z. > - Module B also does X, Y & Z and can seamlessly replace module A >
Agree, and to clarify this even more: If module C needs X which is provided by module A and B: - A and B should be seamless replaceable (as you said) - C should allow easy selection (for the user) of another module that provides X This second point might look redundant, given the first one, but it might be necessary since seamless replacement of modules won't be easy to achieve OR a user may want to use a module that does not support the standard namings. An approach for this second point is the usage of a dependency_class parameter (details in the Google Doc), but I'm sure the collective wisdom here may find a better solution. Also this interoperability should be somehow managed at Modulefile level (and with the puppet module command), so that I can use B even if in the Modulefile is required A. This part, which involves changes in Puppet's code, has to be somehow addressed sooner or later, IMHO. > Reusable > > - Supports multiple operating systems with a clear & standard pattern for > adding additional OSes > - General capabilities of module can be switched on or off or lightly > modified. Ex., don't manage services or override configuration directory. > > One way that we differ immediately on reusability is that you're pretty > detailed on what you should be able to customize, like package and service > names. I don't disagree with you but I'm trying to start from a higher > level and see whether that's sufficient. I'm not sure what the balance is > regarding # of class parameters in use / ease of use. > The idea is that you are not forced to provide all the "proposed" parameters, but if some of the parameters you provide in your module have the same function of the ones proposed, you should call them in the "standard" way. We might classify parameters in different ways, so that some should be considered somehow recommended (for a "standard module"), other optional, and other "extra" or "enhanced", because more specific and exotic (thinking about the ones related to monitoring/firewalling, for example). > Introspectable > > - Code follows style guide and other patterns so that contributions are > more easily made and managed. > - Puppet should be able to programmatically tell us about defined class > parameters and their default values. (yeah, this is theoretical atm) > +1, but with a small note: Even if I think it can be useful to provide some recommended patterns for modules design, this is a somehow more controversial and debatable matter (as the discussion with John in this thread may suggest) so I would not couple it strictly with the discussion about naming standards which it's, imho, more easy to stage and manage. No problems for me in facing all the different problematics behind modules standards, but I'd suggest to make small steps and begin with the easier ones, since putting too many topics in the cauldron and keeping them tied together might make harder any improvement. > Are these three goals and their values what we're all striving for with > this proposal? If not, what am I missing or getting wrong? > I think we agree on the overall goals. Actually you've added the one about introspectability that is a welcomed addition but it partly relies upon features that are still missing in Puppet. My starting approach was to concentrate on things that can be done now, with the current Puppet versions (I'd leverage on Puppet 3, though, since we are talking about the future modules) and giving common names to common sense parameters seemed a minimal logical step. Nevertheless, it's important to conduct this discussion in pair with the expected evolutions of Puppet, so that we can define something that makes sense now and will make sense in the future. > > Thanks for kicking this off Al. I also care deeply about this stuff and > will be trying to carve off more time each week to help you continue to > explore it. > Thanks to you Ryan for supporting this, PuppetLabs' influence on the matter is vital. 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.
