Nigel, It frightens me a bit that I think the "correct" solution, will be to replicate what the distros are doing in Puppetforge. Basically turning puppetforge into a massive cross distro metadata repo, with very strict contribution standards and rules. This would involve strong rules for curated modules that would require manpower to vet (and to contribute the modules).
Maybe, we might want to extend modules so that there are two namespaces, one for curated forge modules and another for local modules. (Making the "local module" namespace the default for backwards compatibility.) One example of a potential rule would be to require that official modules support a mandatory set of popular OSes. Don't allow more than one official module per package. e.g.: In the curated section of forge there will be one MySQL module. (not to get too ahead of the cart, but I envision a time when you can instantiate a MySQL service by just telling puppet to use the Forge MySQL module, puppet handles downloading and installing the module and figuring out what OS you are running and with the help of the native package management, installs and configures the basic MySQL service.) The official modules will be curated such that if there is a a common resource they need to manage that resource will be split into a separate singular dependency module, that incorporates the requirements of all dependent forge modules. (Not a bag of common resources in a single module, but rather a separate module for each shared resource.) Maybe, I am overthinking this, but I think this is the "right" solution, that may require more resources to implement than the community has available. That leaves us what to do about "defined". (Or was that a different thread?) In the case of defined, my group has only ever used it once in almost 4 years, but it seems from the discussions that there are others still using it. Maybe the answer is provide a real alternative first, and then go about deprecating it? We wouldn't miss it, but I could see the challenges of rewriting a codebase that depends on it, and I wouldn't want that rewrite enforced on me, without a solid alternative. Cheers, Brian P.S. - No one is going to really love this solution, including myself, but that doesn't necessarily mean it shouldn't be done. On Sat, Jan 28, 2012 at 9:18 PM, Nigel Kersten <ni...@puppetlabs.com> wrote: > I just wanted to post to this thread to primarily encourage you all to > keep brainstorming, and to make it clear that I'm paying close attention. :) > > > > -- > Nigel Kersten > Product Manager, Puppet Labs > > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > -- <http://aws.amazon.com/solutions/solution-providers/brandorr/> -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
