Hey Al, sorry. I went on holiday and then had to unbury myself. I guess it's time I get my opinion out there.
On Mon, Jul 1, 2013 at 2:33 AM, Alessandro Franceschi <a...@lab42.it> wrote: > > > 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>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. > As in, this is the class you're expected to depend on? That's going to be a little hard to standardize on. Sometimes it's a resource you want, sometimes a fact, maybe it's multiple classes. > 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. > I couldn't agree with you more here. We've got to allow for dependencies to be interchangeable and I think this is most elegantly solved (for the moment) at the module level, with its metadata and Forge ecosystem. That said, I think that's best left to another thread. > > >> 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). > OK. I could get on board with that though I do think that the overall set of parameters needs to be pruned down. Which parameters could be better addressed with module/puppet changes? The dependency_class parameter mentioned above seems like a good 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. > I don't follow. Class parameters and their default values is controversial? > 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. > I respect that, but I think you'll agree that we may need big changes to solve some of these problems. I'm in a position to help with that, so let's strive for it! > > >> 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. > I don't mean to beat this point to death, but I'm more interested in exploring what changes are needed to really solve the reusability goals we've discussed. I do think there's some value to having standard class parameters for module authors to align themselves around but it's not going to solve the problem IMO, it's just going to make it a little easier. That said, I would like to simultaneously collaborate on the parameter standards, with an eye towards consolidation. Would you like that feedback in your Google Doc or the new GitHub repo? > > >> >> 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. > Yeah, no problem -- this is an awesome problem to solve. I am sorry that our involvement is not as active as you'd like. We're pushing really hard over here to clear the Forge and Puppet Labs modules backlog. I can only thank you for your passion and ask for your continued patience. > > 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. > > > -- Ryan Coleman | Modules & Forge | ryanycoleman on twitter & #puppet IRC -- 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.
