I agree with your assessment of what should stay and what should not with the exception of tidy and mount. Those two are not platform specific from what I can tell.
However, I would like to request that, if they stay, that improvements/enhancements to native types are either included or excluded whole hog. Yes, I'm pulling in my last submission to the group provider set but either the whole chart of providers should be supported (if possible) or it shouldn't. We shouldn't have parts in the native code and parts flying around as additions because, well, it's difficult to test. Ref: https://tickets.puppetlabs.com/browse/PUP-1298 (my first cut was to update the native type itself but it was indicated that we should not be adding providers even if they filled the provider chart in the docs) Try pulling in this test and running rspec tests using it though. I can't figure out how to get them to work successfully. Trevor On Tue, Oct 7, 2014 at 10:36 PM, Daniele Sluijters < daniele.sluijt...@gmail.com> wrote: > 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 > <https://groups.google.com/d/msgid/puppet-dev/ae97ed56-fdd9-40f0-abea-4a819fef5615%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaug...@onyxpoint.com -- This account not approved for unencrypted proprietary information -- -- 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/CANs%2BFoVX7_nDQJpcqyF8xd22z1Qh1sMYoxi60M6Kj_6n3G1Lyg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
