We're look into ways to implement change management to our puppet configurations, and this approach is very interesting as it seems very straight forward and easy to maintain (btw, it's very similar to the approach described on http://fnord.no/sysadmin/puppet/staging). As described on that web site, I'm thinking we could implement a script (i.e. svn-update script) that checks out individual modules based on specific tags. I'm guessing you have created a similar type of script.
When making changes to a module, I'd like to make sure that that module is tested in development, testing and qass before being implemented on production servers. An idea would be to have that svn-update script enforce this policy by ensuring that only modules that are tagged for a specific environment can be updated on that particular environment. Let me illustrate by an example: Support we have module "ldap". When it's ready for testing, we tags it for example like this "ldap_1.0_testing". In order to update it in the testing environment, the svn-update script verifies that that the module is suffixed by the keyword "testing". Furthermore, when ready for the qass environment, we tag the module again with "ldap_1.0_qass", so that the svn-update script will allow us to update the qass environment. Have anyone else developed a similar setup to ensure that modules are not updated on production servers before being tested on qass servers? Any comments on the idea I just described? Another issue I need to solve is how to test new versions of the puppetmaster. I'd like to organize testing of puppetmaster the same way l described above. In order to do this I suspect I need to figure out two things: 1) How can I install to versions of the RPM package containing puppetmaster on the same linux server? 2) How can I have the old puppetmaster hosting for example "production and qass", at the same time as having the new puppetmaster hosting "testing" and "development"? Do I have to have them running on different ports, and manually modify the /etc/puppet.conf file for each wrt modulepath etc? Best regards, Kenneth Holter Only tags that have for example "<module-name>_<module-version_testing" can be updated in the qass env, and On Mon, Dec 21, 2009 at 4:44 PM, 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<puppet-users%2bunsubscr...@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 > > > Hope that helps. > > 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<puppet-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.
