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 <mikishap...@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
