On Mon, Dec 21, 2009 at 11:45 AM, Douglas Garstang <doug.garst...@gmail.com> wrote: > 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.
Yes, that's what: [development] modulepath = /etc/puppet-development/modules:/etc/puppet-development/services manifest = /etc/puppet-development/manifests/site.pp does. When a client connects and says it is in the development environment (either by --environment= or it's puppet.conf), the modules it uses are from /etc/puppet-development/modules, not from /etc/puppet/modules. This way, we keep production and staging (QA) versioned (svn tag). Anything in development is a moving target (svn trunk). Each puppet directory on the puppetmaster are complete checkouts of subversion (either trunk or a tag/branch). Matt -- 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.
