Puppet users - Apr 2011 - Setting puppetmaster modulepath from inside manifests

Greetings all
Am trying to solve a problem, not entirely sure I''m approaching it
from the right angle.

Setting up a reasonably big site (servercount in the four digits) with
puppetmaster and clients (puppet 2.6.x). We are required to have
versioned modules (base SOE module, app X module, app Y module, etc -
all with multiple classes etc inside) managed on an underlying SVN
repository.

A requirement is that a node should be configured entirely within
node.pp, should not rely on extra per-server specifics added to
puppet.conf on either puppetmaster or agent ends

Different nodes are required to have different versions of same
modules.
site.pp imports files with node definitions. Node definitions must end
up including a base class of a nominated version and any number of app
classes, each with its respective version.

The approaches to choose from I''m aware of are:
[approach A] ALL versions of a module are simultaneously available to
all servers via one big ubercatalog. SVN trunk, as well as SVN tag
directories (containing historic versions of modules) are added to
modulepath on the puppetmaster via puppet.conf

The node file then says:
include base-1.2.3

Problems with this approach:
1. We can''t have two versions of "base". We need to call them
differently. Thus, when a new SVN ''tag'' is made, it needs to
be
branched out, and all references inside - base::class::foo be changed
to base-1.2.3::class::foo in a multitude of places in the module.
Doing this manually is impractically tedious. Doing this automatically
is unacceptably risky.
2. The catalog will keep getting lumpier and bloatier with time and
might someday reach a point where something breaks.

[approach B]  A node can cherry-pick its module version (injecting
manifest code into the node definition that tells puppetmaster to use
a custom modulepath?)
This sounds good, but how does one do this?

[c] Scrap modules altogether and just import the correct manifests,
using the directory path to the manifests to nominate the SVN tag
directory with the right version, then doing:
include base


I don''t like [c] (especially as my modules have both files and
templates that need to be referenced as well), but it''s the only thing
I''ve managed to make work so far.

Can anyone suggest how to make modules work to suit these
requirements?

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

Hi,

Don''t like the sound of your predicament :)

Could you use different module paths like you do with
''environments''. Traditionally these are used for
''production, testing, devel'' but there in no limit on what you
call them.

Then the nodes subscribe to that particular environment that points to your
specific module path.

Everything remains in svn. 

Cheers,
Den

On 07/04/2011, at 11:45, Miki <mikishapiro@gmail.com> wrote:
> Greetings all
> Am trying to solve a problem, not entirely sure I''m approaching it
> from the right angle.
> 
> Setting up a reasonably big site (servercount in the four digits) with
> puppetmaster and clients (puppet 2.6.x). We are required to have
> versioned modules (base SOE module, app X module, app Y module, etc -
> all with multiple classes etc inside) managed on an underlying SVN
> repository.
> 
> A requirement is that a node should be configured entirely within
> node.pp, should not rely on extra per-server specifics added to
> puppet.conf on either puppetmaster or agent ends
> 
> Different nodes are required to have different versions of same
> modules.
> site.pp imports files with node definitions. Node definitions must end
> up including a base class of a nominated version and any number of app
> classes, each with its respective version.
> 
> The approaches to choose from I''m aware of are:
> [approach A] ALL versions of a module are simultaneously available to
> all servers via one big ubercatalog. SVN trunk, as well as SVN tag
> directories (containing historic versions of modules) are added to
> modulepath on the puppetmaster via puppet.conf
> 
> The node file then says:
> include base-1.2.3
> 
> Problems with this approach:
> 1. We can''t have two versions of "base". We need to call
them
> differently. Thus, when a new SVN ''tag'' is made, it needs
to be
> branched out, and all references inside - base::class::foo be changed
> to base-1.2.3::class::foo in a multitude of places in the module.
> Doing this manually is impractically tedious. Doing this automatically
> is unacceptably risky.
> 2. The catalog will keep getting lumpier and bloatier with time and
> might someday reach a point where something breaks.
> 
> [approach B]  A node can cherry-pick its module version (injecting
> manifest code into the node definition that tells puppetmaster to use
> a custom modulepath?)
> This sounds good, but how does one do this?
> 
> [c] Scrap modules altogether and just import the correct manifests,
> using the directory path to the manifests to nominate the SVN tag
> directory with the right version, then doing:
> include base
> 
> 
> I don''t like [c] (especially as my modules have both files and
> templates that need to be referenced as well), but it''s the only
thing
> I''ve managed to make work so far.
> 
> Can anyone suggest how to make modules work to suit these
> requirements?
> 
> Much 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.
> 
-- 
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.