Bug 524451 - Review Request: puppet-module-yum-development - Puppet module for yum (development)
Review Request: puppet-module-yum-development - Puppet module for yum (develo...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
Fedora Extras Quality Assurance
:
Depends On:
Blocks: FE-DEADREVIEW
  Show dependency treegraph
 
Reported: 2009-09-20 07:32 EDT by Jeroen van Meeuwen
Modified: 2011-01-10 15:02 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-10 15:02:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeroen van Meeuwen 2009-09-20 07:32:08 EDT
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/
Comment 1 Todd Zullinger 2009-09-26 10:11:06 EDT
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.
Comment 2 David Lutterkort 2009-10-08 13:02:58 EDT
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)
Comment 3 Jeroen van Meeuwen 2009-10-11 08:54:05 EDT
(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.
Comment 4 Jeroen van Meeuwen 2009-10-11 08:57:10 EDT
(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)
Comment 5 Jason Tibbitts 2010-11-18 15:07:23 EST
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
Comment 6 Jason Tibbitts 2011-01-10 15:02:16 EST
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.

Note You need to log in before you can comment on or make changes to this bug.