There are some good write ups on this topic at: http://docs.puppetlabs.com/guides/environment.html http://puppetlabs.com/blog/git-workflow-and-puppet-environments/
You are certainly not the first to use this type of workflow. On Fri, Jan 20, 2012 at 6:10 AM, Dan White <y...@comcast.net> wrote: > Thanks for responding. > > This approach is similar to one of the (messy) ideas I have. > > It seems to me that there are no built-in features that will let me do this, > so I am (once again) trail-blazing. > > I like the idea of the Dev/Overlord PM using Puppet/(revision control) to run > the Deputy PM's. That keeps everything in the revision control system. > > Thank you for sharing that. > > "He who receives an idea from me, receives instruction himself without > lessening mine; as he who lights his taper at mine, receives light without > darkening me.” > Thomas Jefferson > > ----- Luke Bigum <luke.bi...@lmax.com> wrote: >> Hi Dan, >> >> A lot of people use a revision control system like SVN or Git, and each >> Puppet Master independently pulls a revision of Puppet code from this >> repository. You could manually control or setup some automatic method of >> upgrading your QA and prod machines to certain revisions. Your Dev >> puppet master then 'decides' what revision your QA and Prod puppet >> masters need to have checked out. There's a few Puppet modules around >> that handle checking out from repositories, or it wouldn't be difficult >> to write your own. >> >> Depending on how many people you have committing to your Puppet >> repository though this could get troublesome, as if I wanted to push my >> revision 10 code to QA, i've also pushed my colleague's revision 7, 8 >> and 9 code which has made changes I wasn't expecting. This is where we >> are at the moment, it's only started to become an issue as more and more >> people get comfortable with puppet. Our next evolution might be to have >> branches for each environment, so if I want to push my code from Dev to >> QA I just have to merge my change from Dev to QA in the Puppet >> repository and (hopefully) not have to worry about anything anyone else >> has been committing to Dev. >> >> On 20/01/12 04:34, Dan White wrote: >> > I have questions about Puppet's scalability. >> > I am looking for info about how one might have multiple cooperating >> > PuppetMasters on a network. >> > >> > I have found old links that talk about merging Puppet and Func, but they >> > all seem out of date. >> > >> > My questions go more toward delegated puppet-mastering rather than data >> > volume as I will attempt to explain: >> > >> > Picture a three-tier operations set-up with development, QA, and >> > production environments. >> > >> > I have set up a Puppet Master in the development environment. >> > I would like to expand the use of Puppet to cover all three environments, >> > but the practice is to minimize cross-traffic as much as possible. >> > >> > So, what I would like to be able to do is have a Master PuppetMaster in >> > dev which feeds two Deputy PuppetMasters in QA and production. >> > Each of the three PuppetMasters would manage the clients in their >> > environment, >> > and the cross-traffic would be minimized to only between PuppetMasters. >> > >> > I have brain-stormed on my own and I have a couple of possibilities, but >> > they all feel like messy hacks so far. >> > So, I thought I'd ask here before trying any of my ideas. >> -- >> Luke Bigum >> Information Systems >> +44 (0) 20 3192 2520 >> luke.bi...@lmax.com | http://www.lmax.com >> LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN >> >> >> The information in this e-mail and any attachment is confidential and is >> intended only for the named recipient(s). The e-mail may not be disclosed or >> used by any person other than the addressee, nor may it be copied in any >> way. If you are not a named recipient please notify the sender immediately >> and delete any copies of this message. Any unauthorized copying, disclosure >> or distribution of the material in this e-mail is strictly forbidden. Any >> view or opinions presented are solely those of the author and do not >> necessarily represent those of the company. >> >> -- >> 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. > -- 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.
