inline On Mon, May 28, 2012 at 04:32:03PM -0700, Anthony Shortland wrote: > Very interesting that you should say that you created a Puppet master for > each environment ... it's the obvious way to accommodate the limits of RPM > packaging while retaining the ability to use Puppet in full agent mode. > Is this considered a best practice? What other considerations drive the > decision to have a Puppet master per environment?
Being able to test puppetmaster upgrades with all supported builds without affecting production. Being able to leave my lab puppetmaster and some agents for a weekend with an angrier chaos monkey chewing on them, and not worry that it's affecting production. Etc., etc., doing things without touching production. > Anthony. > On May 27, 2012, at 5:03 PM, Kristof Willaert wrote: > > Hi, > > [snip] > > * Hack the RPM package names to include a version discriminator > (e.g. "packageV1-1.0-noarch.rpm" rather than > "package-1.0-noarch.rpm") to allow them all to be installed on > Puppet maste > > This is a practice that is already used for the kernel, so it seems like > a legitimate way of working. > > Some time ago, I faced the exact same problem you are describing. One > possible solution I devised was: > > * Use the version of the module in the packagename (as you already > considered) to make multiple versions on one system possible, and > install all modules in the > same basedir, using the version as part of the path, like > /etc/puppet/modules/<modname>/<version>/ > > * Create some script that mimics the functionality of the debian apache > a2enmod, a2dismod scripts (they create symlinks for apache modules) that > creates a symlink > of the version you want in the modulepath of the environment you want > (eg. /etc/puppet/modules/prd/users -> /etc/puppet/modules/users/0.1.2) > > You could also create a simple puppet class instead of the script, to > manage these symlinks. If you use this with hiera, you get a nice yaml > file that contains the > deployed versions of your modules per environment. > > In the end I turned to a different solution (create a puppetmaster for > each environment) because of a few other reasons. But I think the above > should work without lots of problems. > > Kind regards, > > k > -- > You received this message because you are subscribed to the Google > Groups "Puppet Users" group. > To post to this group, send email to [1]puppet-users@googlegroups.com. > To unsubscribe from this group, send email to > [2]puppet-users+unsubscr...@googlegroups.com. > For more options, visit this group at > [3]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. > > References > > Visible links > 1. mailto:puppet-users@googlegroups.com > 2. mailto:puppet-users+unsubscr...@googlegroups.com > 3. 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.
