Hi Ryan Personal and alternative time priorities and availability surely influence the flow of discussion and I definitively have to understand that better in the cases when I've some free time and others not, so sorry everybody for the insistence, and consider the pings about the matter as a way to keep the discussion alive.
On Saturday, July 13, 2013 6:04:34 PM UTC+2, Ryan Coleman wrote: > > 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<javascript:> > > 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. > Well, whatever you need from an external module, in this class (for which the module author provides his default) can be replaced by another class, defined and provided by the users, which is supposed to provide the same resources (or declare classes and defines from other modules ). A (not particular elegant) example is this: https://github.com/stdmod/puppet-elasticsearch/blob/master/manifests/dependency.pp which uses legacy resources (git::reposync from a example42 git module you may not use) and creates some opinionated resources like the init script for the elasticsearch service. Another example is this: https://github.com/example42/puppet-graylog2/blob/master/manifests/dependencies.pp where is used a define like mongodb::user which may have different parameters or name or usage patterns in an alternative mongo module actually used by the graylog2 module user. The same would apply for more common cases where in your module you have to use defines apache::vhost or mysql::grant (at least until we don't define a naming standard also for them specifically, but that's another point), if they can stay in a "replaceable" class the module is more reusable and more easily made cross-compatible. I know this is a somehow partial and naif solution, but it's possible with the current language, and I agree that some higher level solutions that may involve code changes in Puppet can and should be seeked. But IMHO one thing doesn't exclude the other. Having some standard parameters names to refer to the name of classes provided by the module than can be replaced directly by the user, (dependency but maybe also other internally subclasses like user, install or even service and config...) for me it makes sense. > > >> 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. > +1 > > >> >> >>> 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. > I'd say that the list of overall parameters to be considered a sort of "minimal standard requirement" is definitively to prune down, but I don't see any harm in defining standard name patterns for other parameters that are surely not requested by a standard module but may stay there, because the module author considered it worth the effort. But, if there are some proposed parameters names that are considered not only useless but possibly harmful (because they imply a "wrong" design or might create confusion or whatever), then I definitively agree to amend them. For the dependency_class example, for example, I think it's not harmful, at least given the current status of Puppet, but if everybody thinks the opposite... well I won't insist on that and follow the proposed alternative. > > >> >> >>> 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, but how to structure a module yes. For example you may have accept parameters only on the openssh main class, which may or may not include other subclasses or have separated openssh::client , openssh::server (but also openssh::service, params, config) subclasses that can declared directly, each with their own set of parameters. The naming proposal should define patterns for both the cases, without requiring or involving a specific module design. > > >> 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! > Ok. I think we have somehow to narrow down and focus on the different naming proposals and decide which ones are reasonable enough to be considered somehow "obvious" and which ones require a larger and wider angled approach. > > >> >> >>> 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? > I'd say https://github.com/stdmod can be a good shared place where everybody can post and discuss code samples, naming proposals and implementations. I'm open to allow any member / admin request to anybody. And this Google group is the place where higher level discussions have their natural agora. > > >> >> >>> >>> 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. > I think and hope good things can come out about this whole matter at the PuppetConf, maybe in the developer day: it could be a great occasion to gather into live action who is interested in the matter and if we manage, as we are doing, to have some preliminary work /exchange of ideas done before, like sample modules code, patterns and so on, that would make live discussions more focused on real, written grounds. 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.
