On 5 July 2010 11:01, Jean-Baptiste Barth <jeanbaptiste.ba...@gmail.com>wrote:
> For the moment we only have 1 puppetmaster here. I noticed that if I have a > syntax error in one of my included .pp, then puppet runs fail on all nodes > (even if they do not use this recipe), which is not acceptable. More > generally, working directly on production recipes seems too riskee, since > people who will manage those recipes are not devs but sysadmins, which means > poor development skills (and no versionning for the moment). > > I found the documentation about puppet "environments" ( > http://docs.puppetlabs.com/guides/environment.html ) : does anybody use it > here ? I also read some of you have 2 puppetmasters running on different > ports, for test and prod : how do you do that (init scripts available > somewhere? different conf/manifests directories? sync between test and > prod?). Do you have a pool of client machines dedicated to your tests ? Do > you handle this kind of problems directly with your version control system > (post hooks?), or maybe at an other level in your external node provider ? > Mostly echoing Daniel Pittman's comments.. - We use environments a lot. The default production environment is for, well, production. All other environments are for development use. Each has their own SVN branch and Puppet `manifest`/`modulepath`/extlookup directives. - In addition to custom types, providers and facts, flapping back and forth between environments. It's also not possible to have separate fileservers for additional paths between environments. But it's probably not something that will affect you at this stage. - We have virtualised dev/staging machines which reflect the roles of our production machines, only on a slightly smaller scale. Any changes get pushed here and monitored first. We also have some shell scripts which are a shorthand for `--test --noop` to quickly review what is going to happen for a given machine. When we're happy with the results then the changes get merged to production. - Syntax errors are caught by a pre-commit hook. It won't guard against stupid yet syntactically correct code. But it does vastly reduce the time spent dealing with simple humanoid typos. - Be sure to version control your manifests from day one. Without doing so, you'll have no way of knowing who changed what and when. Nor the ability to roll back to a point in history. It will also provide you with an easy mechanism to peer review any code that you're not confident with, as Daniel notes. -- 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.
