W dniu wtorek, 14 stycznia 2014 16:07:29 UTC+1 użytkownik Jason Antman napisał: > > 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 > >
It seems like a prerequisite for the above is a decent, feature reach packaging system for puppet modules. It should provide a way to describe complex dependencies, including expressions such as "or" (e.g. foo >=1.2.3 | bar >= 4.5.6), tools for conflict resolutions, options to hold installed versions, smart upgrades etc. Only then you could ensure that users can be happy mixing custom versions of custom modules and their systems could evolve smoothly in time. Maybe another idea would be to split out the module packager and make it a separate project? :) -- 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/3ec4529c-0e3e-45d3-a0f9-aff989e54352%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
