Puppet users - Apr 2011 - Classes not imported on a directory with the same module name.

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

Basically I have on site.pp an import of multiple classes inside a directory
with import "foo/*" and also a module called "foo"

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

Thanks.
-- 
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 puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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

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.

Regards,
Felix

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Apr 26, 2011 at 8:22 AM, Felix Frank <
felix.frank@alumni.tu-berlin.de> 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.

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.

Thanks


Regards,
> Felix
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> 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 puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> Agree, I should take advantage of autoloader, but how people handle
> those classes where the implementation of multiple modules are required?
I don''t understand this question. More context needed.
> 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.
You can have multiple module paths. Modules still have to be named
distinctly, but you can separate generic modules from those that
implement specific use cases.
> 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.
Apparently, you messed puppet up internally? Possibly a bug.

If you must keep using non-modularized manifests (I hope you don''t),
rename your foo/ directory and change the import statement. That should
fix it, right?

Regards,
Felix

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Apr 26, 2011 at 6:52 AM, Tony G. <tonysk8@gmail.com>
wrote:
>
>
> On Tue, Apr 26, 2011 at 8:22 AM, Felix Frank
> <felix.frank@alumni.tu-berlin.de> 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.
> 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

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Apr 26, 2011 at 11:35 AM, Nan Liu <nan@puppetlabs.com> wrote:
> On Tue, Apr 26, 2011 at 6:52 AM, Tony G. <tonysk8@gmail.com> wrote:
> >
> >
> > On Tue, Apr 26, 2011 at 8:22 AM, Felix Frank
> > <felix.frank@alumni.tu-berlin.de> 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 puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> 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 puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Apr 26, 2011 at 9:54 AM, Tony G. <tonysk8@gmail.com>
wrote:
>
>
> On Tue, Apr 26, 2011 at 11:35 AM, Nan Liu <nan@puppetlabs.com> wrote:
>>
>> On Tue, Apr 26, 2011 at 6:52 AM, Tony G. <tonysk8@gmail.com>
wrote:
>> >
>> >
>> > On Tue, Apr 26, 2011 at 8:22 AM, Felix Frank
>> > <felix.frank@alumni.tu-berlin.de> 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 puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.