Re: [Puppet Users] Multiple environments and mail
On Fri, Jun 18, 2010 at 11:18 -0700, Nigel Kersten wrote: Have you tried --no-report ? That works! Because other long options work as --key=value, I never expected --report=false not to work. Thanks! This could be a bug, I don't use tagmail reports, but it just hit me that it's probably reasonable for --test to imply --no-report as well as the other things it implies. Agreed. Regards, Robert Scheer -- 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.
[Puppet Users] Multiple environments and mail
To facilitate developing, testing and releasing puppet code, we use different environments. That works very well. The only problem is that I cannot prevent puppet from mailing a report, nor direct it somewhere else, when using a different environment. The file /etc/puppet/puppet.conf on the puppetmaster looks like this: -- [main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/etc/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter pluginsync=true templatedir=$confdir/templates color=false [puppetmasterd] autosign=false verbose=true reports=log,store,tagmail [userxxx] manifestdir=/usr/home/userxxx/svn/puppet/manifests manifest=/usr/home/userxxx/svn/puppet/manifests/site.pp modulepath = /usr/home/userxxx/svn/puppet/modules [useryyy] manifestdir=/usr/home/useryyy/svn/puppet/manifests manifest=/usr/home/useryyy/svn/puppet/manifests/site.pp modulepath=/usr/home/useryyy/svn/puppet/modules -- The file /etc/puppet/tagmail.conf contains: -- all:adm...@ourdomain -- The line reports=log,store,tagmail under [puppetmasterd] is what we want for production: if something changes, then adm...@ourdomain get a puppet report. So far so good. Now userxxx is has written a new module and is testing his code on a node called testbox. He runs: puppetd --environment=userxxx --debug. This generates a puppet report to adm...@ourdomain. But the admins do not want to receive this report every time somebody else tests his/her code. Of course every admin could filter away these mails, but that is not a real solution. Adding the option --report=false to puppetd has no effect. Adding report=false to [userxxx] has no effect. Adding reports=log to [userxxx] has no effect. Adding tagmap=/usr/home/userxxx/svn/puppet/tagmail.conf to [userxxx] has no effect. The new tagmap (with another address in it) is completely ignored. Puppet still looks for /etc/puppet/tagmail.conf Is this a bug or am I doing something wrong here? We are using puppet 0.25.4 on both the master and client nodes. Robert Scheer XS4ALL System Administration -- 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.
Re: [Puppet Users] Multiple environments and mail
On Fri, Jun 18, 2010 at 10:34 AM, Robert Scheer r...@xs4all.net wrote: To facilitate developing, testing and releasing puppet code, we use different environments. That works very well. The only problem is that I cannot prevent puppet from mailing a report, nor direct it somewhere else, when using a different environment. The file /etc/puppet/puppet.conf on the puppetmaster looks like this: -- [main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/etc/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter pluginsync=true templatedir=$confdir/templates color=false [puppetmasterd] autosign=false verbose=true reports=log,store,tagmail [userxxx] manifestdir=/usr/home/userxxx/svn/puppet/manifests manifest=/usr/home/userxxx/svn/puppet/manifests/site.pp modulepath = /usr/home/userxxx/svn/puppet/modules [useryyy] manifestdir=/usr/home/useryyy/svn/puppet/manifests manifest=/usr/home/useryyy/svn/puppet/manifests/site.pp modulepath=/usr/home/useryyy/svn/puppet/modules -- The file /etc/puppet/tagmail.conf contains: -- all: adm...@ourdomain -- The line reports=log,store,tagmail under [puppetmasterd] is what we want for production: if something changes, then adm...@ourdomain get a puppet report. So far so good. Now userxxx is has written a new module and is testing his code on a node called testbox. He runs: puppetd --environment=userxxx --debug. This generates a puppet report to adm...@ourdomain. But the admins do not want to receive this report every time somebody else tests his/her code. Of course every admin could filter away these mails, but that is not a real solution. Adding the option --report=false to puppetd has no effect. Have you tried --no-report ? Adding report=false to [userxxx] has no effect. Adding reports=log to [userxxx] has no effect. Adding tagmap=/usr/home/userxxx/svn/puppet/tagmail.conf to [userxxx] has no effect. The new tagmap (with another address in it) is completely ignored. Puppet still looks for /etc/puppet/tagmail.conf Is this a bug or am I doing something wrong here? We are using puppet 0.25.4 on both the master and client nodes. This could be a bug, I don't use tagmail reports, but it just hit me that it's probably reasonable for --test to imply --no-report as well as the other things it implies. Robert Scheer XS4ALL System Administration -- 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. -- nigel -- 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.
Re: [Puppet Users] Multiple environments and mail
On 06/18/2010 02:18 PM, Nigel Kersten wrote: On Fri, Jun 18, 2010 at 10:34 AM, Robert Scheerr...@xs4all.net wrote: To facilitate developing, testing and releasing puppet code, we use different environments. That works very well. The only problem is that I cannot prevent puppet from mailing a report, nor direct it somewhere else, when using a different environment. Unfortunately, tagmail does not do per-environment settings. I put in a feature request for this a while ago, go thumbs it up! -- Joe McDonagh AIM: YoosingYoonickz IRC: joe-mac on freenode When the going gets weird, the weird turn pro. -- 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.
Re: [Puppet Users] multiple environments different manifests not working: solved!
Hello James, Am Friday 12 March 2010 21:49:02 schrieb James Turnbull: the reason for ignoring the different manifests was a setting in /etc/sysconfig/puppetmaster. The settings name is PUPPETMASTER_MANIFEST and was set to my production site.pp. Because of my switch back to webbrick while upgrading puppet the Problem occurs in conjunction with the update. [..] Is this a default RH/Fedora etc setting on one your site had set yourself? No. Default is is: #PUPPETMASTER_MANIFEST=/etc/puppet/manifests/site.pp Every Setting is a comment by default. The Problem was made by myself. Cheers, Hubert -- Hubert Krause Risk Fraud Division INFORM GmbH, Pascalstraße 23, 52076 Aachen, Germany Phone: +49 24 08 - 94 56 5145 E-Mail: hubert.kra...@inform-ac.com, Web: http://www.inform-ac.com INFORM Institut fuer Operations Research und Management GmbH Registered AmtsG Aachen HRB1144 Gfhr. Adrian Weiler -- 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.
Re: [Puppet Users] multiple environments different manifests not working: solved!
Hello list, Am Wednesday 10 March 2010 11:07:14 schrieb Hubert Krause: I was running Puppet server in version 0.24.8 on Srerver and 0.24.4 up to 0.24.8 on client and configured multiple environments. The desired behavior is to have different sets of manifests and modules for my two environments testing and production. But it works only for my modules not for my manifests folders. I discover this behavior because of an the reason for ignoring the different manifests was a setting in /etc/sysconfig/puppetmaster. The settings name is PUPPETMASTER_MANIFEST and was set to my production site.pp. Because of my switch back to webbrick while upgrading puppet the Problem occurs in conjunction with the update. Best regards, Hubert -- Hubert Krause Risk Fraud Division INFORM GmbH, Pascalstraße 23, 52076 Aachen, Germany Phone: +49 24 08 - 94 56 5145 E-Mail: hubert.kra...@inform-ac.com, Web: http://www.inform-ac.com INFORM Institut fuer Operations Research und Management GmbH Registered AmtsG Aachen HRB1144 Gfhr. Adrian Weiler -- 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.
Re: [Puppet Users] multiple environments different manifests not working: solved!
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 13/03/10 2:11 AM, Hubert Krause wrote: Hello list, Am Wednesday 10 March 2010 11:07:14 schrieb Hubert Krause: I was running Puppet server in version 0.24.8 on Srerver and 0.24.4 up to 0.24.8 on client and configured multiple environments. The desired behavior is to have different sets of manifests and modules for my two environments testing and production. But it works only for my modules not for my manifests folders. I discover this behavior because of an the reason for ignoring the different manifests was a setting in /etc/sysconfig/puppetmaster. The settings name is PUPPETMASTER_MANIFEST and was set to my production site.pp. Because of my switch back to webbrick while upgrading puppet the Problem occurs in conjunction with the update. Hi Hubert Is this a default RH/Fedora etc setting on one your site had set yourself? Cheers James Turnbull - -- Author of: * Pro Linux System Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBS5qoviFa/lDkFHAyAQKhpggA2o4pp6/gBkwB5Tj2q330ehHi8g61cOWC /w4ofaQaYKI8wa2DI4JwPgZIvvD/LpgovCgjLe2x6UYJ1e4k4PQKBcDAcNmENelt QijOD864SVwPnkU5c9ZakwsbmrX1MP5RBrgWHzd324iqiVWu9p/TrLpzK/vP+twQ Oa6bRnbJ1Z5/CKBon9rOmmC3HRYT6PTEgPt/+g7pSz+jUMwLlCB0rxCvzsC2Mxfa /ghAR3Yc54ZDEfMZj2zAtsrJ6LNOGv1YMKVqEUScLvHM3tpoD0h3GPIYrVds/81J gIG5bWQIGNGTK3PHDWAwDXsextk4uVi5MVuWRpENasfYjLKXQFAJXw== =zmLG -END PGP SIGNATURE- -- 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.
[Puppet Users] multiple environments different manifests not working
Hello, I was running Puppet server in version 0.24.8 on Srerver and 0.24.4 up to 0.24.8 on client and configured multiple environments. The desired behavior is to have different sets of manifests and modules for my two environments testing and production. But it works only for my modules not for my manifests folders. I discover this behavior because of an upgraded to version 0.25.4 on server and client, but I dont know if it is due to the update. For this update, I've changed the access to the puppetserver from passenger to the build in webbrick. My Clients are CentOS 5.4 and Debian Lenny, my Server is a CentOS 5.4 box. My configuration looks as follows: There are two folders in /etc/puppet: testing and production. On my server the puppet.conf looks like: [main] vardir = /var/lib/puppet logdir = /var/log/puppet rundir = /var/run/puppet ssldir = $vardir/ssl environments = production,testing [production] manifestdir = /etc/puppet/production/manifests modulepath = /etc/puppet/production/modules manifest = /etc/puppet/production/manifests/site.pp [testing] manifestdir = /etc/puppet/testing/manifests modulepath = /etc/puppet/testing/modules manifest = /etc/puppet/testing/manifests/site.pp [puppetmasterd] certdnsnames=puppet-server.fe.example.com:puppet-server.be.example.com:puppet-server.bla.example.com:puppet-server.test-frontend.example.com:puppet-server.test-backend.example.com [puppetd] classfile = $vardir/classes.txt localconfig = $vardir/localconfig server=puppet-server.fe.example.com environment = production On my Clients for the testing environment the puppet.conf file looks like: [main] vardir = /var/lib/puppet logdir = /var/log/puppet rundir = /var/run/puppet ssldir = $vardir/ssl environment=testing environments=testing [puppetd] classfile = $vardir/classes.txt localconfig = $vardir/localconfig server=puppet-server.fe.example.com Did someone have an idea what is going on in my case? best regards, Hubert -- Hubert Krause Risk Fraud Division INFORM GmbH, Pascalstraße 23, 52076 Aachen, Germany Phone: +49 24 08 - 94 56 5145 E-Mail: hubert.kra...@inform-ac.com, Web: http://www.inform-ac.com INFORM Institut fuer Operations Research und Management GmbH Registered AmtsG Aachen HRB1144 Gfhr. Adrian Weiler -- 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.
Re: [Puppet Users] Multiple Environments
Do you mean running puppetmaster on different linux servers? It would probably be the best solution, but I do think I prefer running multiple puppetmasters on one linux server if possible.. How are other people testing new puppetmasters? On Thu, Dec 31, 2009 at 6:42 PM, Scott Smith sc...@ohlol.net wrote: Kenneth Holter wrote: We're look into ways to implement change management to our puppet configurations, and this approach is very interesting as it seems very Even easier: Maintain multiple Puppet infrastructures. Push your code to each as it is ready. Dev puppetmaster, dev puppet clients. Staging puppetmaster, staging puppet clients. Production puppetmaster, production puppet clients. It also will enable you to maintain a staging environment that is as close to prod as possible. -scott -- 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.compuppet-users%2bunsubscr...@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-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.
Re: [Puppet Users] Multiple Environments
Kenneth Holter wrote: Do you mean running puppetmaster on different linux servers? It would probably be the best solution, but I do think I prefer running multiple puppetmasters on one linux server if possible.. How are other people testing new puppetmasters? What?! You mean your puppetmaster binds to every available interface on port 8140? Really? :) -scott -- 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.
Re: [Puppet Users] Multiple Environments
On Fri, 8 Jan 2010, Kenneth Holter wrote: Do you mean running puppetmaster on different linux servers? It would probably be the best solution, but I do think I prefer running multiple puppetmasters on one linux server if possible.. How are other people testing new puppetmasters? On Thu, Dec 31, 2009 at 6:42 PM, Scott Smith sc...@ohlol.net wrote: Kenneth Holter wrote: We're look into ways to implement change management to our puppet configurations, and this approach is very interesting as it seems very Even easier: Maintain multiple Puppet infrastructures. Push your code to each as it is ready. Dev puppetmaster, dev puppet clients. Staging puppetmaster, staging puppet clients. Production puppetmaster, production puppet clients. It also will enable you to maintain a staging environment that is as close to prod as possible. -scott We use multiple puppetmasters and branches. Virtualization makes it easy to spin up new puppetmasters. We have lab environments where we develop and test puppet code and each of those has its own puppetmaster and branch. Some admins have a personal puppetmaster and branch and we'll also spin masters for specific projects. After testing the code in a branch we merge to trunk. Dev and QA systems run off trunk and after the changes pass QA we merge to a prod branch. In the future we're going to take a tag off trunk and release that to the production puppetmasters. We've found that multiple branches can be tricky to keep in sync so we make a point of frequent merges to trunk and rebranching. Otherwise trunk and the branches get so out of sync that merging becomes a real chore. -Eric -- 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.
Re: [Puppet Users] Multiple Environments
Douglas Garstang 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. G. / As I currently use SVN I prefer checking out the hole svn (branches/tags/trunk) to something like /etc/puppetconfig (you may use /usr/share/ or var or whatever you prefer) and create a symlink from /etc/puppet.conf to /etc/puppetconfig/branches/production/puppet.conf. The puppet.conf in trunk is usually used when changing server configuration on a testing puppet master. Both of them describe the production environtment as /etc/puppetconfig/branches/production and development as blah/blah/blah/trunk. So for normal manifest change you work with the production puppet master with environment development, but for config changes of puppet master you work with a different computer which uses the trunk config. Good luck, Silviu -- 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.
Re: [Puppet Users] Multiple Environments
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. G. -- 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
Re: [Puppet Users] Multiple Environments
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. G. -- 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
Re: [Puppet Users] Multiple Environments
Douglas Garstang wrote: On Mon, Dec 21, 2009 at 8:32 AM, R.I.Pienaar r...@devco.net wrote: hello, - Douglas Garstang doug.garst...@gmail.com wrote: http://www.devco.net/archives/2009/10/10/puppet_environments.php [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 really should take some time to just play with this, or at least read the links, wiki pages and samples we've been posting here. Internally - when configured as in the quote above, or on the url in the top bit or on the puppet wiki environment page - puppet will take care of all the serving needs for you. if your client says it's in the environment 'development' then for Matts example it would find files/modules/etc in /etc/puppet-development/modules:/etc/puppet-development/services The devco.net url shows you how you could branch - using svn but git can work too - just a specific module and why that might be a good choice. Just play with it, setup a master and experiment, all the needed information is there, once you play with you'll no doubt have a 'Oh, thats how it work!' moment. I did read the reductive labs documentation (which is unclear as usual), and the devco site before posting here, and again after someone referenced it. I understand the concept of multiple environments quite well, and that's not the issue. The issue is how I integrate this functionality back into subversion such that I don't have to be constantly copying files between development and production. The devco site does NOT show you how you can branch. It says you can do it, and that's about it. It does not address for example the issue of when making a branch, and checking the branch out to work on it, you suddenly have no puppet environment to work in. How do you test? Lastly, I have a functional config presently. I don't want to muck around with it and break it. There's been many a time where I've gotten svn confused by doing constant moves of directories etc to the point where I have to completely blow everything away in that tree and start again. 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. Doug, I am not a version control expert but I think you might be confusing svn branches with cvs branches. As soon as you do: svn cp production development: you've not only made a new puppet environment, you've 'branched' production into development. -- Joe McDonagh Silent Penguin Services Operations Engineer AIM: YoosingYoonickz IRC: joe-mac on freenode Blog: www.colonfail.com -- 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.
Re: [Puppet Users] Multiple Environments
Doug, I am not a version control expert but I think you might be confusing svn branches with cvs branches. As soon as you do: svn cp production development: you've not only made a new puppet environment, you've 'branched' production into development. I'd also recommend using a more fully featured DVCS like Git or Mercurial etc - their capabilities allow for much more flexible approaches. Regards James Turnbull -- Author of: * Pro Linux System Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux) -- 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.
Re: [Puppet Users] Multiple Environments
2009/12/20 Russ Allbery r...@stanford.edu: The advantage of Git branches is that we can much more easily merge or cherry-pick changes between the environments. For example, changes that must be made in production can be made there and then merged into test, so that test stays in sync easily but can maintain separate changes. Our intention is to then cut a new production branch from test every three months and retain two production branches, cutting each production server from the old branch over to the new branch on a quarterly cycle according to the requirements of that production environment. That way, all servers benefit from general architectural changes, but those changes are thoroughly tested first in the test/dev environments (which will all point to the master branch). +1 to Russ' approach. By maintaining branches and creating a lifecycle you can also fit the cycle to your change control, embed it in your ticketing system, etc, etc. Teaches good development lifecycle skills to admins too. :) Regards James Turnbull -- Author of: * Pro Linux System Administration (http://tinyurl.com/linuxadmin) * Pulling Strings with Puppet (http://tinyurl.com/pupbook) * Pro Nagios 2.0 (http://tinyurl.com/pronagios) * Hardening Linux (http://tinyurl.com/hardeninglinux) -- 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.
Re: [Puppet Users] Multiple Environments
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. -- 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.
Re: [Puppet Users] Multiple Environments
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. 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.
Re: [Puppet Users] Multiple Environments
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. G. -- 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.
[Puppet Users] Multiple Environments
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? 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.
Re: [Puppet Users] Multiple Environments
Douglas Garstang doug.garst...@gmail.com writes: 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? Our plan is to do basically that but with Git branches rather than rsync. We currently already have our entire Puppet configuration in a version control system (currently Subversion), and will be converting it to Git and then using Git branches to maintain the separate environments. The advantage of Git branches is that we can much more easily merge or cherry-pick changes between the environments. For example, changes that must be made in production can be made there and then merged into test, so that test stays in sync easily but can maintain separate changes. Our intention is to then cut a new production branch from test every three months and retain two production branches, cutting each production server from the old branch over to the new branch on a quarterly cycle according to the requirements of that production environment. That way, all servers benefit from general architectural changes, but those changes are thoroughly tested first in the test/dev environments (which will all point to the master branch). -- Russ Allbery (r...@stanford.edu) http://www.eyrie.org/~eagle/ -- 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.
[Puppet Users] Multiple environments
So I'm trying to get multiple environments to work with puppet 0.25.1 on ubuntu 8.04 and no matter what I do, puppet just completely ignores any environment setting. There's really next to no information in terms of configuration on the multiple environments documentation page (http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments) other than saying that the following section should be in my puppet.conf file: [main] manifest = /usr/share/puppet/site.pp modulepath = /usr/share/puppet/modules [development] manifest = /usr/share/puppet/development/site.pp modulepath = /usr/share/puppet/development/modules There are other references on web pages and groups to an environments setting under puppetmasterd as well as having a default environment setting in main for the clients but I've tried all of that and nothing works. There's also no reference at all to any environment in debugging mode when I run puppetd --test -- environment=test -d. Am I missing something? Here's a copy of my puppet.conf file: [main] vardir = /var/lib/puppet manifest = /etc/puppet/manifests/site.pp modulepath = /etc/puppet/modules pluginsync = true storeconfigs = true # dbadapter = mysql dbuser = puppet dbpassword = dbserver = mysql.example.com [puppetmasterd] certname=puppet.example.com [testing] manifest=/etc/puppet-testing/manifests/site.pp modulepath=/etc/puppet-testing/modules [production] manifest=/etc/puppet/manifests/site.pp modulepath=/etc/puppet/modules Cheers, Scott --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
