On Mon, Dec 21, 2009 at 8:36 AM, Matthew Hyclak <hyc...@gmail.com> wrote: > On Mon, Dec 21, 2009 at 11:27 AM, Douglas Garstang > <doug.garst...@gmail.com> wrote: >> On Mon, Dec 21, 2009 at 7:44 AM, Matthew Hyclak <hyc...@gmail.com> wrote: >>> On Sun, Dec 20, 2009 at 7:17 PM, Douglas Garstang >>> <doug.garst...@gmail.com> wrote: >>>> On Sun, Dec 20, 2009 at 1:58 PM, Douglas Garstang >>>> <doug.garst...@gmail.com> wrote: >>>>> On Sun, Dec 20, 2009 at 4:57 AM, R.I.Pienaar <r...@devco.net> wrote: >>>>>> hello, >>>>>> >>>>>> ----- "Douglas Garstang" <doug.garst...@gmail.com> wrote: >>>>>> >>>>>>> I'd like to be able to split out my puppet production and test >>>>>>> environments so that I can continue to develop puppet >>>>>>> modules/manifests without breaking production. How are people doing >>>>>>> this? Puppet environments may be one way. I guess I'd have a >>>>>>> main(prod) environment and a test one. When I was finished with >>>>>>> testing, I could rsync the files over to the prod environment. Is >>>>>>> this >>>>>>> how others are doing it? >>>>>> >>>>>> http://www.devco.net/archives/2009/10/10/puppet_environments.php >>>>>> >>>>>> That's how I do it, aim is to avoid many copies of the same module just >>>>>> because we have multiple environments, but still have the ability to >>>>>> create those versions during the dev cycle. >>>>>> >>>>>> not for everyone, but maybe it help you in the right direction. >>>>> >>>>> Thanks to everyone for the replies. >>>>> >>>>> Are you using multiple environments though? And, if using multiple >>>>> environments, how do you structure it? The puppet documentation is a >>>>> bit vague on the subject. For instance, it's not clear to me if you >>>>> would structure it so that you have a top level dir ABOVE puppet >>>>> called prod, test etc, or if you would create subdirs BELOW manifests, >>>>> modules etc called prod, test. >>>>> >>>>> The next question is, where do you branch? If you have a top level dir >>>>> above puppet, I guess that's pretty easy, but if you have multiple >>>>> dirs below manifests, modules etc, then you'd need to branch each >>>>> which becomes more complex. >>>> >>>> Hmmm. I'm not following this here. At the moment I have /etc/puppet, >>>> which is a working copy. Every now and then I commit my changes. I can >>>> add a dev environment to this working copy and safely use that to test >>>> modules and manifests on dev nodes, but there's still no way for me to >>>> roll those changes back to the production environment without some >>>> manual process. >>>> >>>> I could make a branch of /etc/puppet, and check it out, but then I'd >>>> need a second copy of puppetmaster running in a second location to >>>> test it against. I'm using passenger, so maybe I could fire up a >>>> second instance on another port, and maybe that would work. >>>> >>>> If I was to branch the prod dir inside puppet into a dev dir, then >>>> this is kind of where I get lost. If I was to branch /etc/puppet/dev >>>> or simialar, once again I'd need to check it out into a new location >>>> where I could work on it, and test it. This still needs a second copy >>>> of puppetmaster running, and it's actually worse this way because I >>>> don't have all the necessary puppet config from further up the tree. >>>> >>>> Grrrr. >>>> >>>> -- >>>> >>>> You received this message because you are subscribed to the Google Groups >>>> "Puppet Users" group. >>>> To post to this group, send email to puppet-us...@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. >>>> >>>> >>>> >>> >>> We handle this as follows: >>> >>> Puppetmaster has /etc/puppet, /etc/puppet-development, >>> /etc/puppet-staging (among others) >>> >>> /etc/puppet-development -> svn checkout of trunk, updated whenever we >>> feel like it >>> /etc/puppet-staging -> svn checkout of a tag, updated Tuesdays >>> /etc/puppet -> svn checkout of a tag, updated Thursdays (allows 2 days >>> of testing a tag in Staging) >>> >>> puppet.conf contains (in addition to the standard stuff): >>> >>> [staging] >>> modulepath = /etc/puppet-staging/modules:/etc/puppet-staging/services >>> manifest = /etc/puppet-staging/manifests/site.pp >>> >>> [development] >>> modulepath = >>> /etc/puppet-development/modules:/etc/puppet-development/services >>> manifest = /etc/puppet-development/manifests/site.pp >> >> So, Matt, it looks like you have three completely different puppet >> areas (/etc/puppet, /etc/puppet-development and so on). That's kind of >> what I thought I might need to do. There's no point in branching a >> specific directory inside puppet because then you don't have the rest >> of the stuff puppet needs to run, and... I'm not sure how svn feels >> about a branch INSIDE a working copy. >> >> But... how do you serve up those multiple puppet environments? Are you >> running multiple versions of the puppetmaster? I'm using passenger so >> it would seem like it would be fairly easy to run additional >> puppetmasters on different ports, except that I can't find where in >> the passenger config I can change the default /etc/puppet (it's not in >> the conf.d/puppetmaster.conf file). >> >> With multiple puppetmasters running, you would also need to configure >> each client to use a different port. I guess.... that's.... ok as long >> as you aren't changing the role of nodes from dev to prod and back. >> > > There is one puppetmaster (well, mongrel) listening on 8140. > Environments are built in to puppet, so you don't have to do anything > different. We have a different client puppet.conf for each environment > that specifies the right paths. Changing a client from one environment > to another is as simple as "puppetd -t --environment=newenvironment"
I'm not following Matt. If you have multiple base directories, /etc/puppet, etc/puppet-development and so on, how do you serve up content from all three locations at once with a single puppet master? I know there's environments, but are you saying the puppet.conf in /etc/puppet refers to module and manifest dirs that are outside /etc/puppet in /etc/puppet-development? Doug. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
