Puppet users - Apr 2012 - Creating a system module path (starting with Telly)

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I''ve noticed that nobody else has replied to this but as one of the
more
vocal people in the
original discussion I''d like to state that I love the idea of a vendor
and
site module path and
think this is an ideal way to move these things out of the core.  This
proposal is much less
scary than the previous conversations and at this point is actually a
pretty big improvement
over the current situation.

So, +1 from this guy!

On Mon, Apr 23, 2012 at 5:03 PM, Michael Stahnke
<stahnma@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 Developers" group.
> To post to this group, send email to puppet-dev@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-dev+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-dev?hl=en.
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com.
To unsubscribe from this group, send email to
puppet-dev+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en.

Sounds good.

One problem that I have with the forge is that the extent to which the 
modules have been tested is not clear to me.  Can I take it that the core 
modules that ship with puppet will have been through a similar testing 
cycle as puppet itself?


On Monday, April 23, 2012 11:03:39 PM UTC+2, Michael Stanhke
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 view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/LyPHnvAgjQ4J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Apr 24, 2012 at 1:53 AM, Bill Proud <billproud@yahoo.com>
wrote:
> Sounds good.
>
> One problem that I have with the forge is that the extent to which the
> modules have been tested is not clear to me.  Can I take it that the core
> modules that ship with puppet will have been through a similar testing
cycle
> as puppet itself?
This is still unclear.  The modules moving in a system module path
will have that type testing. Other modules have varying degrees of
testing and we have plans to improve basically everything having to do
with modules and the forge in that space.

Mike

>
>
> On Monday, April 23, 2012 11:03:39 PM UTC+2, Michael Stanhke 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 view this discussion on the web visit
> https://groups.google.com/d/msg/puppet-users/-/LyPHnvAgjQ4J.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

+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 <stahnma@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+unsubscribe@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: jwarburton@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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

+1 here

As a distribution packager, a clear place to put things specific to the
distribution is a big win for me. I''ve struggled in the past decided
whether to package the clean upstream sources, or to add my own tweaks
as well. To date, I''ve kept it clean, but this makes it easier to
mix-and-match the two, and still be able to trace whether a problem
lies in my distribution module or somewhere in the Puppet core.

Greg
- --
IRC: gwmngilfen
www.github.com/GregSutcliffe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+ea0EACgkQ8O7RN8oK65O7ywCfYkmbP04gwn2x9641D0p3B0cf
ZRAAn3RpalobnbuyvQBcodGTY6tS7ULq
=Pix6
-----END PGP SIGNATURE-----

-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.