Jean-Baptiste Barth <jeanbaptiste.ba...@gmail.com> writes: > Is there a canonical way to manage my recipes' release process? I mean test > it before they're pushed in production.
Not "canonical", as far as I know. > 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. We work on this by keeping the puppet configuration in Subversion. We then have a Makefile at the top level which runs a puppet syntax check on any modified file before a commit. While the puppet check option is pretty terrible[1], it does catch the most gratuitous syntax errors before they get into the repository. > 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). You should explain to your current sysadmins that they are not good enough, and that if they don't improve you will hire better sysadmins — seriously. That said, wrapping up the process in something like a Makefile that will do the Subversion commit, and using appropriate hooks so that the push to production is automatic means you can work around almost anything: All you have to do is document the point-and-drool version of the instructions, then make sure they are tasked by their manager to follow those instructions.[2] Also useful is a culture of code review: when they write puppet code it should be complete and thorough, not "experimenting on the production systems", so they should be able to have a second member of staff review their change *before* they are allowed to commit it. > I found the documentation about puppet "environments" > ( http://docs.puppetlabs.com/ guides/environment.html ) : does anybody use > it here? Yes. Other than the semi-documented limitations about custom types and providers, we use them to good effect. They allowed me to set the standard for my sysadmin staff to have them test everything before they release. > 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?). I wouldn't bother with this, for all that it would get different types: it seems over-kill for the return on the investment. > Do you have a pool of client machines dedicated to your tests? Sometimes. Other times we rely on testing the modified manifest in place. The former, using a dedicated test machine, is vastly preferable. Mostly, though, I think your problem will be best solved by getting the other sysadmins doing the right thing — which might mean getting management involved to make sure it actually happes. Regards, Daniel Footnotes: [1] It doesn't do *ANY* validation of types, so you can have something obviously stupid like 'file { "foo": requiref => blah }' and it passes. It would be really nice if it checked even just that the keys were vaguely valid. [2] Of course, this will take a few rounds of them finding the flaws in the instructions, and you improving the document, but eventually... -- ✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- 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.
