Red Hat Bugzilla – Bug 524451
Review Request: puppet-module-yum-development - Puppet module for yum (development)
Last modified: 2011-01-10 15:02:16 EST
Spec URL: http://puppetmanaged.org/releases/puppet-module-yum-development.spec SRPM URL: http://puppetmanaged.org/repos/f12/SRPMS/puppet-module-yum-development-1.0-1.src.rpm Description: Puppet module for managing yum (this is the development branch) The "-development" part is necessary for the user to maintain the ability to stage environments. I'm not exactly sure whether this is the best way to do it, but with a "-testing" and "-production" version of this package, a user would be able to configure the following in /etc/puppet/puppet.conf: [puppetmasterd] (...snip...) environments = production,testing,development (...snip...) [development] modulepath = /var/lib/puppet/modules/development: \ /var/lib/puppet/puppetmanaged.org/modules/development [testing] modulepath = /var/lib/puppet/modules/testing: \ /var/lib/puppet/puppetmanaged.org/modules/testing [production] modulepath = /var/lib/puppet/modules/production: \ /var/lib/puppet/puppetmanaged.org/modules/production One could argue that the released version is independent from the different staging environments a user is running, in which case we could drop the "-development" part of the package, and go with something similar to: [puppetmasterd] (...snip...) environments = production,testing,development (...snip...) [development] modulepath = /var/lib/puppet/modules/development: \ /var/lib/puppet/puppetmanaged.org/modules/ [testing] modulepath = /var/lib/puppet/modules/testing: \ /var/lib/puppet/puppetmanaged.org/modules/ [production] modulepath = /var/lib/puppet/modules/production: \ /var/lib/puppet/puppetmanaged.org/modules/ == About puppetmanaged.org == puppetmanaged.org provides one singular type of modules (more information about different types of puppet modules at http://puppetmanaged.org/?q=node/2) suitable for Enterprise Linux as well as Fedora. This module (the Yum module) is the first in a series of puppet modules that would be submitted for inclusion in Fedora and EPEL. For a complete list of modules, see http://git.puppetmanaged.org/
I presume the idea is that the module files shipped in the package should not need to be edited? If not, would they be better placed in /usr/share/puppet/modules/<source>/<module>? (Or .../modules/<source>/<environment>/<module> if you have different content to ship in development, testing, and production versions of the module.) Then, users could create symlinks in /var/lib/puppet (or where ever) to meet their own environments layout. This might well be something to bring up on the puppet-dev or -users list. I know the common modules haven't gotten very far yet, but I'm sure other puppet users have given this problem some thought and it might be beneficial to try and come up with a somewhat standard layout for shipping module packages. Plus, then it could be documented on the puppet wiki and potentially save you some work writing a nice README.Fedora.
I would hold off on this until the module metadata discussion has settled upstream. At puppetcamp, we agreed that the metadata should make it possible to generate an RPM for the module automatically. File system layout etc. should at least match whatever upstream recommends (and we should make sure that recommendation is sane for us)
(In reply to comment #1) > I presume the idea is that the module files shipped in the package should not > need to be edited? If not, would they be better placed in > /usr/share/puppet/modules/<source>/<module>? (Or > .../modules/<source>/<environment>/<module> if you have different content to > ship in development, testing, and production versions of the module.) > > Then, users could create symlinks in /var/lib/puppet (or where ever) to meet > their own environments layout. > Not a very bad idea. /usr/share/puppet/puppetmanaged.org/development/yum/ could probably be a better location for these packaged modules, which indeed would not need to be changed by the user (presumably). > This might well be something to bring up on the puppet-dev or -users list. I > know the common modules haven't gotten very far yet, but I'm sure other puppet > users have given this problem some thought and it might be beneficial to try > and come up with a somewhat standard layout for shipping module packages. > Plus, then it could be documented on the puppet wiki and potentially save you > some work writing a nice README.Fedora. The documentation for these type of modules is extensive anyway, since it covers various use-cases (though not all of them). Obviously documentation is always a work in progress, but here's a recent version: http://www.puppetmanaged.org/documentation/Reference_Guide-Modules-Yum_Module.html I'm not sure getting the people working on Puppet Common Modules on board is going to make this any more fast or any more sustainable at this point, given as how Puppet Common Modules has not made any significant progress.
(In reply to comment #2) > I would hold off on this until the module metadata discussion has settled > upstream. At puppetcamp, we agreed that the metadata should make it possible to > generate an RPM for the module automatically. > > File system layout etc. should at least match whatever upstream recommends (and > we should make sure that recommendation is sane for us) What is the module metadata discussion exactly? Do you have a reference? Where is the discussion on filesystem layout (which is distribution specific anyway, it won't make much sense to have that discussion be put upstream entirely, and come to another deadlock in differences between Operating Systems and distributions)
After seeing this ticket sit around for well over a year now and honestly having no clue at all what it's supposed to be about, I have to ask if anyone watching this has any intention of moving it forward. Honestly, I can't really review it because I know nothing at all about puppet
Well, nobody seems to care and all I can gather from IRC conversations is that this is a bad idea. So I'm going to risk flameage and close this; if someone really cares they can reopen.