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?

Thanks!



>
> --
> 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.
>
>


-- 
Tony
http://blog.tonyskapunk.net

-- 
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.

Reply via email to