I''ve been running puppet for a couple of years without using environments. Now, I manage more servers and I think it''s time to implement puppet environments. I have a couple of questions about design best practice. Probably 80% of the modules in use across the various environments would be common to all environments. To avoid duplication of modules, I want to have a separate directory of common modules, and specify two modulepaths in the environment declaration, like this: [resnet] modulepath = $confdir/environments/resnet/modules:$confdir/modules manifest = $confdir/environments/resnet/manifests/site.pp My question is, can I put a module named "httpd" in my common module directory, and then in specific environments have subclasses like "httpd::vhost1", "httpd::vhost2", etc? How will the module fileserving work? As I''m refactoring my whole puppet environment this is a good opportunity to "do things right" so any advice about managing multiple environments, sharing modules, extending classes, etc, will be gratefully received. Cheers, Jonathan -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
> My question is, can I put a module named "httpd" in my common module > directory, and then in specific environments have subclasses like > "httpd::vhost1", "httpd::vhost2", etc? How will the module fileserving > work?The autoloader will not support having one module spread over two modulepaths like you want - it will stop at the first module, so if it finds httpd in /modulepath/1 it''s never going to find httpd::vhost1 in /modulepath/2 Even if that did work it would be unwise and confusing. A better idea maybe to have a httpd class in your common module and then your vhosts in a separate class namespace (sites::vhost1)... that should work. Regards Craig -- Craig Dunn Professional Services Puppet Labs Inc. http://www.puppetlabs.com -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
On 21/02/13 14:16, Craig Dunn wrote:> >> My question is, can I put a module named "httpd" in my common module >> directory, and then in specific environments have subclasses like >> "httpd::vhost1", "httpd::vhost2", etc? How will the module >> fileserving work? > > The autoloader will not support having one module spread over two > modulepaths like you want - it will stop at the first module, so if it > finds httpd in /modulepath/1 it''s never going to find httpd::vhost1 in > /modulepath/2 > > Even if that did work it would be unwise and confusing. A better idea > maybe to have a httpd class in your common module and then your vhosts > in a separate class namespace (sites::vhost1)... that should work. >Thanks for your message. I discovered through testing that the autoloader does not support this behaviour. I had sort of resolved to implement your suggestion although it seems a little bit messy. Taking a step back, are there any better solutions? I want to achieve a common repository of modules, and a handful of environments with different sysadmins, who will be able to call upon the common modules, include them, and extend them in their own environments. Surely there must be some sort of prior art? :) Cheers, Jonathan -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
On 02/21/2013 03:23 PM, Jonathan Gazeley wrote:> > Thanks for your message. I discovered through testing that the > autoloader does not support this behaviour. I had sort of resolved to > implement your suggestion although it seems a little bit messy. > > Taking a step back, are there any better solutions? I want to achieve a > common repository of modules, and a handful of environments with > different sysadmins, who will be able to call upon the common modules, > include them, and extend them in their own environments. Surely there > must be some sort of prior art? :)I believe that the best way to achieve this is to put your modules in source control, preferably with multiple repositories like git. Each environment can thus be a branch of the main environment. All the voodoo of keeping up-to-date etc. happens outside of puppet, which is a good thing imo. HTH, Felix -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscribe@googlegroups.com. To post to this group, send email to puppet-users@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.