Issue #2716 has been updated by Robin Bowes.

I posted this to the dev list, but thought I'd include it here too:

I've thought about this and I currently believe that over-riding classes
in the search path would be a very simple yet very powerful way to
extend puppet's capabilities.

With the current implementation, it is a right royal pain to override
module behaviour. A simple change could make this much easier.

Having slept on it, I think what I'd actually like to see is for puppet
to check for the existence of the *class* rather than the module. So, if
I write "include foo", then puppet should look for:

modulepath1/foo/manifests/init.pp
modulepath2/foo/manifests/init.pp

Further, if I write "include foo/bar", then puppet should look for:

modulepath1/foo/manifests/bar.pp
modulepath2/foo/manifests/bar.pp

and, importantly, it shouldn't stop the search & barf when it finds the
module dir "modulepath1/foo" but can't load
"modulepath1/foo/manifests/init.pp". Instead, it should try the other
elements of the search path, ie. explicitly checking for the class
rather than just the module.

I think this adds a lot of power and usability with adding a great deal
of complexity. I don't buy the argument that this would make puppet
unduly complex - it will actually make it much more simple to customise
"generic" modules without having to re-implement them totally separately.

I would even go so far as to argue that the current behaviour is
unintuitive. I certainly didn't expect puppet to look for just the
module name (ie. the first section of the class name) in the module path
rather than the full class name (yes, I realise it's called "modulepath"
not "classpath"!)

Can we please re-visit this issue?

To be clear, what I want is some way to override classes easily. This
behaviour change is most straight-forward way I've seen to achieve this.

----------------------------------------
Refactor #2716: Provide some way to override puppet classes
http://projects.reductivelabs.com/issues/2716

Author: Robin Bowes
Status: Rejected
Priority: Normal
Assigned to: 
Category: modules
Target version: 
Affected version: 0.25.1rc1
Branch: 


I like to try and write generic puppet modules, ie. they are standalone as much 
as possible and should work in copied and pasted into another puppet 
environment. However, sometimes I may want to use a generic module but override 
the configuration.

I generally write my modules like this:

<pre>vsftpd
|-- files
|   `-- vsftpd.conf
`-- manifests
    |-- config.pp
    |-- init.pp
    |-- install.pp
    `-- service.pp</pre>

init.pp contains sometihng like this:

<pre>class vsftpd {
    require vsftpd::install, vsftpd::config, vsftpd::service
}</pre>

I had hoped that I could override classes by using modulepath like:

<pre>site/modules:generic/modules</pre>

I would put my generic modules in the generic/modules tree and over-ride 
specific class by putting them in the site/modules tree.

So, I created a vsftpd tree (as above) in generic/modules and created the 
following tree in site/modules:

<pre>vsftpd
`-- manifests
    `-- config.pp</pre>

I also added a module for my test node:

<pre>node
`-- manifests
    `-- a001.pp</pre>

a001.pp contains:

<pre>class node::a001 {
    include vsftpd
}</pre>

When I run puppetd --test on node a001, I get this error:

<pre># puppetd --test
info: Retrieving plugin
err: Could not retrieve catalog from remote server: Error 400 on SERVER: Could 
not find class vsftpd in namespaces node::a001 at 
/etc/puppet/site/modules/node/manifests/a001.pp:3 on node 
a001.private.statcounter.com
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run</pre>

It seems that puppet is finding site/modules/vsftpd and assuming that the 
vsftpd class is in site/modules/vsftpd/manifests/init.pp, which of course it 
isn't.

I suggest that puppet should look for <modulename>/manifests/init.pp (not just 
<modulename>) in each element of $modulepath before deciding that it can't find 
<modulename>. This would allow classes to be over-ridden.


-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://reductivelabs.com/redmine/my/account

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Puppet Bugs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/puppet-bugs?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to