On Tue, Apr 26, 2011 at 9:54 AM, Tony G. <[email protected]> wrote: > > > On Tue, Apr 26, 2011 at 11:35 AM, Nan Liu <[email protected]> wrote: >> >> On Tue, Apr 26, 2011 at 6:52 AM, Tony G. <[email protected]> wrote: >> > >> > >> > On Tue, Apr 26, 2011 at 8:22 AM, Felix Frank >> > <[email protected]> wrote: >> >> >> >> Hi, >> >> >> >> On 04/22/2011 06:48 PM, Tony G. wrote: >> >> > Hi all, >> >> > >> >> > Found a situation on which all classes inside a directory are >> >> > ignored, >> >> > this when the directory name is the same as a module name. >> >> > >> >> > err: Could not retrieve catalog from remote server: Error 400 on >> >> > SERVER: >> >> > Could not find class bar at >> >> > /opt/puppet/test/nodes/gnucloud.tonyskapunk.net.pp:2 on node >> >> > gnucloud.tonyskapunk.net <http://gnucloud.tonyskapunk.net> >> >> > >> >> > Basically I have on site.pp an import of multiple classes inside a >> >> > directory with import "foo/*" and also a module called "foo" >> >> >> >> this is a strange requirement indeed. Can you shed any light on why you >> >> want such a structure? It sounds undesirable, even though it should >> >> still work. >> > >> > The idea behind this is to use modules as generic as possible to be >> > implemented by any other class, in this case directory 'foo' will >> > contain >> > classes with specific modules, e.g. a server class which implements >> > http, >> > mysql, and so. >> >> >> >> > Running debug on the master I see only the module is imported, this >> >> > looks like a ruby thing, but since I'm not good at ruby I better ask, >> >> > why is being ignored? >> >> > >> >> > debug: importing '/opt/puppet/test/modules/foo/manifests/init.pp' in >> >> > environment test >> >> > >> >> > Details: >> >> > Server/Client: 2.6.7 >> >> > Node has: import bar >> >> > bar is a class inside "foo" directory that is imported in site.pp >> >> >> >> This should be "include bar" then. >> >> >> > Correct it was a typo, I'm using "include bar" >> > >> >> >> >> Import is a feature that should be considered deprecated. >> >> Try and organize everything into modules and exploit the autoloader, >> >> i.e. make another module "foo_module" with all the classes currently in >> >> disorganized .pp-files in your manifests/foo/ directory and only do >> >> >> >> include foo_module::bar >> >> >> >> without any import statements. There is less pain (and better >> >> performance I feel) down that road. >> >> >> > Agree, I should take advantage of autoloader, but how people handle >> > those >> > classes where the implementation of multiple modules are required? >> > My concept of modules(including structure) is a source of generic >> > reusable >> > classes by other specific classes that will be placed somewhere and thus >> > imported at some point. >> >> The classes are loaded from modules in modulepath in the order of >> their precedence. >> >> So modulepath=/path/a:/path/b >> >> If you have module foo in both /path/a/foo and /path/b/foo, include >> foo will load the module in /path/a and ignore /path/b. > > Thanks Nan, this explains why the modules in my modulepath were loaded and > later when attempting to import in site.pp the other directory it was simply > ignored. > >> >> > I'm curious about the performance part but mainly on how puppet and/or >> > ruby >> > is loading those classes, as it seems to me like is ignoring my classes >> > inside the directory once a module with the same name is loaded. >> >> So if you want to take advantage of this behavior, put your class in a >> module, and put that module in a module path that have >> precedence/priority over the other modules with the same name. >> >> >> Thanks, >> >> Nan > > The other part I'm interested as well is the way to organize/structure > modules, I currently have modules very generic and configurable, to reuse > code as possible on other classes or in nodes, something like: > /path/to/environment/ > modules/ > http/ > files/ > templates/ > manifests/ > mysql > files/ > templates/ > manifests/ > ldap > files/ > templates/ > manifests/ > Then I have a directory for classes that represent type of servers making > use of the modules, for that I need to import the classes inside this > directory and I do that on site.pp(that's why I found this situation), > something like: > /path/to/environment/ > classes/ > webserver.pp > dbserver.pp > ldapserver.pp > ldapclient.pp > etc... > If importing classes is not recommended as Felix replied earlier, what is > the suggested approach for situations like this?
I don't have a great suggestion other than refactor your code so classes are in modules and not imported. Since we don't recommend or use imports to discover classes, I don't know the behavior of import vs. module precedence. If you want to use the current layout you can try the following: use a manifest dir path of /path/to/env/classes, and modulepath of /path/to/env/modules, the first for import classes, the second for modules conforming to puppet module requirement. Since I haven't done any testing, your mileage may vary. Thanks, Nan -- You received this message because you are subscribed to the Google Groups "Puppet Users" 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-users?hl=en.
