Issue #2716 has been updated by Robin Bowes.
Peter Meier wrote:
> > 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:
>
> [...]
Er, that's not over-riding the class, it's replacing it. Suppose you have a
module where init.pp is:
<pre>class app { include app::install, app::config::, app::service</pre>
Suppose I create site-app::service - how does that get used in the app module?
It doesn't. I'd have to write a site-app module that contains:
<pre>class site-app { include app::install, app::config::,
site-app::service</pre>
And then I'd have to use "include site-app", rather than "include app"
> 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'm not sure exactly what you mean by "a shadowed class" but the public modules
will be used and loaded as normal, unless they are over-ridden by a class with
the same name that appears earlier in the module path. So, if you include a
public class then it will just get used, unless you've explicitly over-ridden
it with some other class. I don't feel that this is anything particularly
controversial.
> 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:
>
> [...]
> or
> [...]
>
> as the way to go.
Again, that involves modifying the public module, unless you're suggesting that
all public modules should use that code pattern for all files that they include?
----------------------------------------
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
-~----------~----~----~----~------~----~------~--~---
