Hi list, During the contributors summit preceding Puppetconf 2014 an effort was started to remove Nagios from Puppet core. This effort is currently tracked in https://github.com/puppetlabs/puppet/pull/3165 and and PUP-1077.
I'm going to jump the gun a bit here but once this lands we have a few questions to answer: * What should be moved out of core * Under which namespace should we put this ## What should be moved out of core I think that what should stay in core are those 'building blocks' that without them would make Puppet completely useless or are otherwise tied into Puppet. Consider if you will that we shipped no types and providers at all, which would be the first you need. Personally that list comes down to: file, package, service, exec user and group. I consider those the building blocks of Puppet and especially the first four make up most of what people do in manifests. I would also keep resources, notify, stage and schedule around and the filebucket because of how they influence Puppet's behaviour and the behaviour of other resources. The aforementioned types are also platform agnostic, which brings me to my next point: types and providers that are specific to a (subset of) platform(s) should not be in core. If we now sing the "one of these things does not belong here" song that would mean I would like to oust: augeas, computer, cron, host, interface, k5login, macuathorization, mailalias, maillist, mcx, mount, nagios_*, router, scheduled_task, sel*, ssh*, storage, tidy, vlan, yumrepo, zfs, zone, zpool. Essentially, the rest. This is not to say that Puppet shouldn't ship with them, I'm just saying they should not be part of 'core' but instead should be pulled in at package time in the same way we're trying to do with the nagios nightmare. The idea behind this is to make Puppet core as small as possible and by decoupling so many of the types and providers from core have much more leeway and flexibility when it comes to making changes to said types and providers. I'm also of the belief that having them separate from core will lower a certain barrier that people feel with regard to doing things in core. It would hopefully also relieve the platform team a bit and allow those types and providers to move quicker than the core release cycle when the need arrises. ## Namespaces For Nagios I've pulled the stuff into puppet-community/puppet-nagios_providers which will in time show up as puppet-community/nagios-providers on the Forge. This is mostly because no one really wants maintainership of the nagios stuff so it's a good place to 'graveyard' them and who knows, maybe someone will show up and start taking care of them. As for the other types and providers, I'm not entirely sure where we should put them. If they remain in the puppetlabs namespace there will be certain expectations about Puppet Labs still reviewing and managing that code as well as doing more release testing. Depending on if they want to carry that responsibility or tie themselves to that puppet-community might be the better place to drop those. So, feedback? Should we move anything else out of core? If so, what and based on which criteria? Does PL want to carry them in their own namespace or should we move most of this to puppet-community? P.S The puppet-community space on Github is open to everyone who wants to contribute to it, include PL employees. It's just not tied to Puppet Labs, governance wise, which gives us a bit more freedom to move things around and break stuff every now and then. -- Daniele Sluijters -- 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/ae97ed56-fdd9-40f0-abea-4a819fef5615%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
