+1 A couple of requests: - Notifications on module updates: https://projects.puppetlabs.com/issues/12587 - Testing - I'd like to confirm these module paths support environments
John On 24 April 2012 07:03, Michael Stahnke <stah...@puppetlabs.com> wrote: > There was some discussion and concern about moving the Nagios > types/providers out of the core area of Puppet for Telly. We made a > mistake of talking about a point solution to a problem rather than the > vision on where we’d like it to go, and why. We’ve attempted to > outline this a bit more so you can hopefully have a better > understanding of our ideas. As always, feel free to comment and voice > concerns. This isn’t set in stone and at this point is a proposal. > > == The Problem == > > Bundling types and providers into the core of Puppet has a few problems. > > The most important problem is that it ties releases of the types or > providers to releases of core Puppet. That is a pretty slow moving > (for stability) system, and it is also a system where most of the > investment goes into supporting new releases rather than improving > older releases. > > We want to keep our core stable, while allowing the community platform > experts, distro maintainers and other users to enhance the experience > with certain aspects of Puppet without having to wait for the next > major release. > > The secondary problem is that it plays favourites - some platform > types are in core, others are not. Some monitoring systems, or disk > management systems are in core, others are not. That doesn't reflect > the real importance of those types, or that some are more special or > more stable than others - just happenstance of time. > > On the other hand, having Puppet work out of the box is awesome. You > should be able to install Puppet and immediately get started, managing > your platform and generally doing awesome things. > > Puppet with no types, and no providers, is not awesome. It can't do > anything - and "install twenty things, then ..." is not a good > introductory experience. > > == Proposed Solution == > > We want to take some of the great lessons from other platforms - Perl, > Python, and Ruby - and apply them to this problem: > > We are proposing to pull more types and providers out of Puppet, so > they get the benefit of an independent release cycle, and the > advantages of full forge integration. > > We also propose to have a "system" module path: a set of modules that > ship with core Puppet, taken from the forge, and available by default > at install time. They will ensure that Puppet is still awesome out of > the box - but that you can list modules and their versions, and can > update freely. > > We also plan a "vendor" module path, and a "site" module path. Other > platforms have shown the value of this: when distributions package > Puppet, they might want more or different modules to support their > systems better. Allowing them to drop into the vendor module path and > operate in the same way as our system modules makes it easy to use > normal modules in an awesome way. > > Finally, the "site" module path allows for easy deployment of modules > through other packaging systems like yum and apt, internally to > companies and sites that want a different path for versioning modules. > They separate the mutable path used by the local tool and the managed > path for self-packaged modules. > > This seems to offer the best of both worlds: we can take full > advantage of the strengths of modules, but without giving up the > awesomeness of Puppet that does great things out of the box. > > -- > 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. > > -- John Warburton Ph: 0417 299 600 Email: jwarbur...@gmail.com -- 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.
