Class Naming Convention

[Douglas Garstang]

So, this has always puzzled me a bit. By convention, init.pp contains
one class, named the same as the module. However, what is the
convention when the module may have multiple external access points?
Say you have a module called 'syslog' which provides both a client and
a server class. I typically have used syslog::server and
syslog::client. I've ended up using this convention more than init.pp
because I don't know when I first put the class together exactly what
it's going to do. In module mymodule, rather than create init.pp with
class mymodule, I'll call it mymodule::base or something and stick it
in base.pp. Confused...

Doug

[Garrett Honeycutt]

Not all classes are meant to be directly included by nodes. A common
practice would be having a module where you might have a base class,
such as syslog and other sub classes, such as syslog::client and
syslog::server. Class syslog would contain resources that were common to
both syslog::client and syslog::server (ie: they both have a package and
a config file). Both syslog::client and syslog::server might include (or
possibly inherit) the syslog class. In this setup, a node might include
syslog::server or syslog::client, but not syslog directly. When using
this pattern, be sure to comment in your base class that it is not meant
to be included directly.

-g

--
Garrett Honeycutt

206.414.8658
http://puppetlabs.com

[Douglas Garstang]

Garrett, thanks. Aware of all that, but I'm not sure you really answer
my question. :)

Doug.

[Denmat]

Well you can leave init.pp blank, ie,
class name {
}

Then you can put whatever you like in the module's manifest dir.

I tend to write 90% of modules with the following:
name::config
name::install
name::service
name::client
name::server

All of those refer to individual .pp files of course.

Then something like:
include name::server

HTH
Den

[jcbollinger]

In fact, init.pp can be entirely empty.  If you have a class with the same name as the module then the autoloader expects to find it in init.pp, but such a class is not required as far as I know.  I'm not on the most recent Puppet at the moment, but I definitely have working modules with empty init.pp.

If init.pp serves any essential purpose beyond its significance to the autoloader, it seems to be simply to (redundantly) mark the directory containing it as a module's base manifest directory.


John

[Douglas Garstang]

I guess you would normally include ::client or ::server, and it would
in turn, include (inherit?) ::config, ::install and ::service?

Ie:

class foo::client {
include foo::config
include foo::install
include foo::service
}

If variables are defined in ::config, does that cause any issues with scope?

Doug.

[Douglas Garstang]

On Fri, Aug 17, 2012 at 9:33 AM, Douglas Garstang

So... I just gave this a try, and variables I defined in ::config have
gone out of scope in ::install. *sigh*

Doug.

[llowder]

On Friday, August 17, 2012 11:43:43 AM UTC-5, Douglas wrote:

>
> If variables are defined in ::config, does that cause any issues with scope?

So... I just gave this a try, and variables I defined in ::config have
gone out of scope in ::install. *sigh*

Of course they would.. you just have to fully qualify them. module::config::variable
 

Doug.

[Garrett Honeycutt]

I would be careful of using imperative terms such as install, configure,
build..

Puppet ensures state, so these words can be misleading.