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.
