This is kind of an argument against moving these things out of the core in the first place in my opinion. The fact that you can now have multiple versions of the nagios provider is just worse than having a single copy. Before at least I could update to 2.7.x and be assured all my providers were at the same version, now I have to deal with all the module updates (which only grows as time goes on) and constantly deal with checking them into git, managing them, testing them with various versions of the client.
I get why you're doing this but as an end user this is just causing me more work and making me do more testing and a lot more management. At least before I could rely on having a broad set of core resources. Now we're going in the opposite direction. Maybe I'm just a grouchy old sysadmin but now I can't just rely on yum.puppetlabs.com to provide my resources and that means time out of my day to update them and push them into git. In the workflow we've instigated at work I cannot just throw in an update and push it - I have to create branches, run tests, open tickets. With things provided by puppet's core I just have to get approval to update the client in one easy push. Maybe I'll just make /etc/puppet/modules/ for modules imported directly from the forge (and unedited in any way) and instigate easier rules around updating these. Sorry if this turned into a bit of a "GET OFF MY LAWN" post. On Mon, Apr 16, 2012 at 8:45 PM, Michael Stahnke <stah...@puppetlabs.com>wrote: > 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. > > Mike > > > > > > > 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 > > > > -- > 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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
