On Tue, Jan 14, 2014 at 7:07 AM, Jason Antman <[email protected]> wrote:
> 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.) > Just for clarity here, there is more testing around PE than Puppet. However, there aren't really additional tests in the PE system that Puppet doesn't run on Puppet itself (other than some platform coverage, e.g, AIX, at least to the best of my knowledge). Most of the additional testing comes from Puppet working with a specific version of Facter, working with PuppetDB working with a UI working with Passenger and a specific version of Ruby, etc, etc, etc. > 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). > Just for clarity here: it's all warranty free. See section 7 of the Apache License. http://www.apache.org/licenses/LICENSE-2.0.txt. > > 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]> 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. > > > -- > 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. > -- 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/CAMto7LJVXeBmi2HXmN1tb2%2Bg0Ugfm2OXymX5JBvFYuBNBsHjMQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
