For the next major Puppet version, code-named Telly, we have some changes coming. This is the first in a series of emails around these changes and may require some input from the community.
For Telly, the nagios types will be moved into a module. This allows them to be iterated on in isolation from the rest of Puppet's core release cycle and process. In the future we have plans to move several other types into modules that can be individually maintained, improved, tested and used.
The module for Nagios will be available on the Forge.
The upgrade path is the thing we need some feedback about. The basic steps to upgrade would be to setup a Telly master, and then install the Nagios module via the Puppet Module Tool, which ships integrated with 2.7.13+ and Telly.
The only caveat with this is that if, in the past, you were relying on the Nagios types and forget to install that module (or are unable to for some reason), you would get a failure. The best proposal we could come up with was to have the platform team add some code that lets the user know that the Nagios types have moved. This basically moves this into a 'fail-well' state. We'll try to provide the best information possible to the end-user about what is going on.
Is that an acceptable path moving forward? Comments and discussion welcome.
By 2.7.13+ of course Mike means 2.7.14 and later (because 2.7.13 was a security release). Look for an rc of 2.7.14 later today with the module face included.
<stah...@puppetlabs.com> wrote: > For the next major Puppet version, code-named Telly, we have some > changes coming. This is the first in a series of emails around these > changes and may require some input from the community.
> For Telly, the nagios types will be moved into a module. This allows > them to be iterated on in isolation from the rest of Puppet's core > release cycle and process. In the future we have plans to move several > other types into modules that can be individually maintained, > improved, tested and used.
> The module for Nagios will be available on the Forge.
> The upgrade path is the thing we need some feedback about. The basic > steps to upgrade would be to setup a Telly master, and then install > the Nagios module via the Puppet Module Tool, which ships integrated > with 2.7.13+ and Telly.
> The only caveat with this is that if, in the past, you were relying on > the Nagios types and forget to install that module (or are unable to > for some reason), you would get a failure. The best proposal we could > come up with was to have the platform team add some code that lets the > user know that the Nagios types have moved. This basically moves this > into a 'fail-well' state. We'll try to provide the best information > possible to the end-user about what is going on.
> Is that an acceptable path moving forward? Comments and discussion welcome.
> Mike Stahnke > Community Manager
> -- > 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.
Michael Stahnke wrote: > For the next major Puppet version, code-named Telly, we have some > changes coming. This is the first in a series of emails around these > changes and may require some input from the community.
> For Telly, the nagios types will be moved into a module. This allows > them to be iterated on in isolation from the rest of Puppet's core > release cycle and process. In the future we have plans to move several > other types into modules that can be individually maintained, > improved, tested and used.
> The module for Nagios will be available on the Forge.
> The upgrade path is the thing we need some feedback about. The basic > steps to upgrade would be to setup a Telly master, and then install > the Nagios module via the Puppet Module Tool, which ships integrated > with 2.7.13+ and Telly.
Is it possible to package these modules for distros? In the past, we've had a few requests to do this for third-party modules but we didn't do this because there wasn't really any standard for it. With puppet module tool being integrated now, perhaps that's something that can be reconsidered.
I'm thinking that for folks using rpm, they'd rather see an update that pulls in the same fucntionality as they had before. And even for new installs, I'd personally prefer to install these things via rpm. If I wanted to use a secondary package management system, I could use gems or eggs or CPAN, but I don't. ;)
I think it's good to split out these things, as it would allow us to properly add a nagios dep to the hypothetical puppet-module-nagios package.
-- Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I am free of all prejudice. I hate everyone equally. -- W. C. Fields
On Mon, Apr 16, 2012 at 7:36 PM, Todd Zullinger <t...@pobox.com> wrote: > Michael Stahnke wrote:
>> For the next major Puppet version, code-named Telly, we have some changes >> coming. This is the first in a series of emails around these changes and >> may require some input from the community.
>> For Telly, the nagios types will be moved into a module. This allows them >> to be iterated on in isolation from the rest of Puppet's core release cycle >> and process. In the future we have plans to move several other types into >> modules that can be individually maintained, improved, tested and used.
>> The module for Nagios will be available on the Forge.
>> The upgrade path is the thing we need some feedback about. The basic >> steps to upgrade would be to setup a Telly master, and then install the >> Nagios module via the Puppet Module Tool, which ships integrated with >> 2.7.13+ and Telly.
> Is it possible to package these modules for distros? In the past, we've had > a few requests to do this for third-party modules but we didn't do this > because there wasn't really any standard for it. With puppet module tool > being integrated now, perhaps that's something that can be reconsidered.
> I'm thinking that for folks using rpm, they'd rather see an update that > pulls in the same fucntionality as they had before. And even for new > installs, I'd personally prefer to install these things via rpm. If I > wanted to use a secondary package management system, I could use gems or > eggs or CPAN, but I don't. ;)
> I think it's good to split out these things, as it would allow us to > properly add a nagios dep to the hypothetical puppet-module-nagios package.
> -- > Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I am free of all prejudice. I hate everyone equally. > -- W. C. Fields
On Mon, Apr 16, 2012 at 11:36 AM, Todd Zullinger <t...@pobox.com> wrote: > Michael Stahnke wrote:
>> For the next major Puppet version, code-named Telly, we have some changes >> coming. This is the first in a series of emails around these changes and >> may require some input from the community.
>> For Telly, the nagios types will be moved into a module. This allows >> them to be iterated on in isolation from the rest of Puppet's core release >> cycle and process. In the future we have plans to move several other types >> into modules that can be individually maintained, improved, tested and used.
>> The module for Nagios will be available on the Forge.
>> The upgrade path is the thing we need some feedback about. The basic >> steps to upgrade would be to setup a Telly master, and then install the >> Nagios module via the Puppet Module Tool, which ships integrated with >> 2.7.13+ and Telly.
> Is it possible to package these modules for distros? In the past, we've > had a few requests to do this for third-party modules but we didn't do this > because there wasn't really any standard for it. With puppet module tool > being integrated now, perhaps that's something that can be reconsidered.
> I'm thinking that for folks using rpm, they'd rather see an update that > pulls in the same fucntionality as they had before. And even for new > installs, I'd personally prefer to install these things via rpm. If I > wanted to use a secondary package management system, I could use gems or > eggs or CPAN, but I don't. ;)
Note that as soon as you adopt environments, you end up having multiple locations on disk that you want modules to be installed into, which doesn't fit very well with traditional package management systems.
> I think it's good to split out these things, as it would allow us to > properly add a nagios dep to the hypothetical puppet-module-nagios package.
On Mon, Apr 16, 2012 at 11:36 AM, Todd Zullinger <t...@pobox.com> wrote: > Michael Stahnke wrote:
>> For the next major Puppet version, code-named Telly, we have some changes >> coming. This is the first in a series of emails around these changes and >> may require some input from the community.
>> For Telly, the nagios types will be moved into a module. This allows them >> to be iterated on in isolation from the rest of Puppet's core release cycle >> and process. In the future we have plans to move several other types into >> modules that can be individually maintained, improved, tested and used.
>> The module for Nagios will be available on the Forge.
>> The upgrade path is the thing we need some feedback about. The basic >> steps to upgrade would be to setup a Telly master, and then install the >> Nagios module via the Puppet Module Tool, which ships integrated with >> 2.7.13+ and Telly.
> Is it possible to package these modules for distros? In the past, we've had > a few requests to do this for third-party modules but we didn't do this > because there wasn't really any standard for it. With puppet module tool > being integrated now, perhaps that's something that can be reconsidered.
> I'm thinking that for folks using rpm, they'd rather see an update that > pulls in the same fucntionality as they had before. And even for new > installs, I'd personally prefer to install these things via rpm. If I > wanted to use a secondary package management system, I could use gems or > eggs or CPAN, but I don't. ;)
Todd, welcome and I feel your pain. Trust me, I pushed every way I could to use native packages as our module deliver mechanism. However we have some odd requirements that make things not work as well with RPM (or deb, or gems). Basically we need a mechanism to allow multiple versions installed into separate environments (paths on disk). That sort of ruled out traditional packaging systems, without doing some installation and symlink-selection magic. Even then, there were some issues.
Something like pm2rpm and pm2deb is very likely something we'll need to make the lives of Puppet Users happy. It should be fairly simple and we'll want to be sure that the default module path is something that is FHS compliant.
We'll also want to work with Jordan and see if we can get packaging Puppet Modules (in this format) as an option with FPM. I think FPM already does some Puppet Module stuff, so it may not need any real updates.
> I think it's good to split out these things, as it would allow us to > properly add a nagios dep to the hypothetical puppet-module-nagios package.
> -- > Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > I am free of all prejudice. I hate everyone equally. > -- W. C. Fields
