I thought I'd throw in my 2 cents, as a long-time puppet user, current PE customer, and community member trying to make more code contributions...
First off, this thread has been great. I was going to quote a few replies, but there have been so many good ideas, that's sort of pointless. I fully support Daniel's plan to push tier2 directly to modules. More than that, I'd like to see it implemented in a way that I (an "advanced user") can easily opt-out of a given tier2 module (did someone say Nagios?) and replace it with something external. I'd like to share a realization that I recently had, which could perhaps be an aid in delineating what's tier1 vs tier2: I'd always assumed that everything that shipped with Puppet was tested. Period. It was unclear to me until I started trying to use puppetlabs' forge modules with PE (and found that one or two in particular didn't work), and started actually submitting some PRs against core, that there were varying levels of support, and that just because Puppet might ship with a provider for X doesn't mean that it's fully validated and tested against that (i.e. Andy's comments about FreeBSD). (As an aside, I'd also assumed that what I remember hearing years ago was true, and there was no internal split between PE and FOSS - that PE was "just FOSS in a prettier box, with support and some value-adds", presumably that the only testing done to PE and not FOSS was around Console and packaging. Andy's comment that PE is tested on more platforms than FOSS was something I'd always written off as anti-Puppet conspiracy theory.) As such, for the benefit of the community, I'd suggest that anything that (a) isn't fully tested and vetted by PL (whatever that means) or (b) is known to be broken (i.e. naginator) be split out into tier2, as modules, with a clear delineation to explain to users that these are essentially sub-par and warranty-free. (I suppose this largely falls in line with Dustin's comment about Python core vs modules). I can't say I have a clear picture of how this would work... but as a probably 'more advanced' user of Puppet, I'd like to see this happen in a way that makes it easy to not only run a new version of a tier2 module, but also perform a wholesale replacement of it with something from the community (once again, reference to the nagios types). As such, I guess I'd be in favor of installing them *somewhere* outside of the core and adding a config directive (true by default) to automatically append that path to modulepath. That would be transparent to users who don't care about it, and for people like me, allow us to cherry-pick specific modules to append to our modulepath, and ignore others. Ideally the Modulefile format would be updated to understand this, so it would be easier to specify requirements for things that might no longer be present in a given puppet install. Versioning and dependencies are another strong argument in favor of moving directly to modules. If tier2 "things", i.e. the FreeBSD provider, are maintained and versioned separately but included in the "puppet" distribution proper, how does a Forge module or arbitrary piece of code declare that it needs a specific version of the provider? If I pull in the latest git version but am still running "Puppet 3.5.0" how is that communicated to modules? We know how to do this with puppet as a whole ($::puppetversion) or with modules (Modulefile, and the various tools that support it), but it's unclear to me how this would work if, for example, the FreeBSD package provider version wasn't inextricably tied to the puppet version. Just some thoughts. I'm very excited to see this change, both for the implications it has around nagios, and to possibly throw my name in the hat as a maintainer for the `pip` package provider. -Jason Antman On 01/13/2014 09:56 PM, Nan Liu wrote: > 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] > <mailto:[email protected]>> wrote: > > On Sun, Jan 12, 2014 at 2:38 PM, Kylo Ginsberg > <[email protected] <mailto:[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. -- 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/52D552B1.3000204%40jasonantman.com. For more options, visit https://groups.google.com/groups/opt_out.
