Removing types/providers from core

[Daniele Sluijters]

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

[Felix Frank]

Hi there,

agree with most of this, see comments below.

On 10/08/2014 04:36 AM, Daniele Sluijters wrote:
>
> 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.

I'm not sure about resources - especially the purging options don't live
up to some users' expectations, and we encouraged at least one
contributor to take his enhancements to a separate type in his own
module. The reason being that resources is a high-ish maintenance type.
Perhaps this would be an opportune time to yank this metatype out of the
core as well.

> 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.

I'm not actively opposed to transferring this to the community, but I
see value in PL retaining the proverbial reigns. We do get a fair say in
many things as it stands, no particular need to stretch our wings
further. And on the other hand, it can be useful to have an
authoritative voice at the table, in such times when we fail to reach
clear consent. (Granted, I can't recall a particular example for such a
situation in this particular community.)

This does boil down to Puppet Tier Modules as discussed early in the,
yes? Sounds all the more sensible to leave the modules with PL.

Thanks for getting this under way.

Cheers,
Felix

[Trevor Vaughan]

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

--
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+...@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.

--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

[John Bollinger]

On Wednesday, October 8, 2014 5:46:31 AM UTC-5, Trevor Vaughan wrote:

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.

I agree that Tidy is not platform-specific.  Moreover, some corners of its behavior interact fairly closely with File, which seems to be destined to remain in the core.  Tidy should stay there, too.

Mount, on the other hand, is at least platform-restricted as far as I understand: it isn't applicable to Windows, and in principle, it might not be applicable to various other present and (mostly) future operating systems that have a filesystem model different from UNIX's.  That's not to say that I have any specific desire for Mount to be un-friended, though.

John

[Daniele Sluijters]

I completely missed 'tidy', that was a copy-paste gone wrong. I really have no preference towards that one but John makes a good argument that the way it interacts with file would warrant it to stay in core.

Mount on the other hand can only work with mount/umount and is chained to /etc/fstab or /etc/vfstab. It currently seems to support Solaris, a host of *BSD's, OS X and Linux-y distributions. Windows is definitely out of the question as is AIX (I believe) since that would involve /etc/filesystems and "manually" managing entries there is a recipe for disaster.