Nigel, I just wanted to add, if we do go this route, we should work to support private "forges" (module repos) as well.
Cheers, Brian On Sun, Jan 29, 2012 at 1:39 AM, Brian Gupta <brian.gu...@brandorr.com>wrote: > 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/> > > -- <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.
