Issue #2716 has been updated by Peter Meier.
> By "the way we discussed in this thread", I presume you mean the
> multiple-source thing for files? This is a partial solution IMHO. For one, it
> mean the module has to contain site-specific information - goodbye standard
> modules. Also, it only covers over-riding files. Suppose I want to over-ride
> an app::service class?
No, a module doesn't have to contain site-specific information, why do you
think that? And no it doesn't only cover overriding files. If I want to
override app::service I can do:
<pre>
class site-app::service inherits app::service {
include app::service::some::part::disable
include site-app::service::some::new::part
}
</pre>
Why I see it as a problem:
Imagine somebody is looking at the public module, changes one class with a
change that would definitely go into the common public modules. But the change
isn't applied as the loader is loading the class from the other module path.
This isn't imho the expected behaviour. So as far as I understood your request
the class in the public module would be something of a shadowed class, which
will never be used nor loaded. What if this class gets updated in the upstream
and introduces new required behaviour in other classes? You would have to track
that and copy this behaviour over. If I include a class I'd like to know
exactly which class is loaded, especially regarding the common modules project.
I yet don't see fully how the current approach limits you in overriding classes
from public modules.
For the file sources I see an approach like:
<pre>
file{'/etc/exim/exim.conf':
source => [ "puppet://$server/modules/site-exim/${fqdn}/exim.conf",
"puppet://$server/modules/site-exim/exim.conf",
"puppet://$server/modules/exim/exim.conf" ],
}
</pre>
or
<pre>
file{'/etc/exim/exim.conf':
source => [ "puppet://$server/files/exim/${fqdn}/exim.conf",
"puppet://$server/files/exim/exim.conf",
"puppet://$server/modules/exim/exim.conf" ],
}
</pre>
as the way to go.
----------------------------------------
Refactor #2716: Provide some way to override puppet classes
http://projects.reductivelabs.com/issues/2716
Author: Robin Bowes
Status: Re-opened
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
-~----------~----~----~----~------~----~------~--~---
