It's great the core type/provider is getting a serious review. On Mon, Jan 13, 2014 at 4:20 PM, Andy Parker <[email protected]> wrote:
> On Sun, Jan 12, 2014 at 2:38 PM, Kylo Ginsberg <[email protected]>wrote: > Even later to the party, but I agree :) The alternative of a contrib >> directory could muddy the waters so that there were 3 locations a given >> type/provider could land (core/contrib/module), when the current 2 >> locations (core/module) suffice. Easy to imagine extra bike-shedding on >> where something lands and/or the contrib directory becoming a failed >> experiment wasteland. >> >> > Ok, so the initial idea of keeping a "contrib" inside the puppet codebase > for some things under active development seems to be a losing one. What > about the trimmed down idea of having it be a staging ground for pulling > things out (in which case "contrib" is a terrible name for it)? > The less the better, since this could get pretty confusing to troubleshoot. Maybe a mechanism which collapse the providers to avoid a large module sprawl. At minimum a tool to track everything: puppet resource_types - package core - service core - database /etc/puppetlabs/puppet/modules/mysql ... puppet resource_providers package - package: |- apt /etc/puppetlabs/puppet/modules/apt/ v1.0 |- gem /usr/share/puppet/modules/gem v1.0 ... However, one question I have about shipping modules with puppet as >> discussed in this thread: are people thinking this means modules >> pre-installed in /usr/share/puppet/modules, or that the packaging step >> would merge/patch the tier2 modules into puppet proper? >> >> > I'm interested in this as well. > Maybe merging would be better, at least to force detection of colliding providers (you can't install two versions of the yum provider). > If the former, is that overly disruptive to sites that specify >> modulepath? If the latter, does that complicate sites that want to upgrade >> one of the packaged-in modules using pmt? I haven't thought this through, >> so there may be a perfectly simple answer. >> > Installing to /usr/share would be a pain for things like vagrant (which assumes a single puppet module path). I can see other issues with testing in vagrant, and there would be quite an increase in .fixture.yml just to do something basic. For puppet upgrades there's no assumption that modules are compatible and I think handling upgrades of type/provider modules would be similar process (Puppetfile/librarian-puppet or r10k). Nan -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CACqVBqCNGvA8AuB_%3DFZ_HXpQPAs08TnbgXA%3D%2BtBzt3aQMPxckQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
