[chef] Re: Re: Re: New user feedback and questions

[Olivier Gutknecht < >]

On Sep 7, 2009, at 10:05 PM, Joe Van Dyk wrote:

On Mon, Sep 7, 2009 at 11:12 AM, Adam Jacob < "> > wrote:

On Mon, Sep 7, 2009 at 3:57 AM, Brian Candler< "> > wrote:

> (3) In the environment where I work, the most likely need for chef is in
> distributing config files [*].
>
> So I'm looking as to ways we can make this as safe and simple as possible
> for the sysadmins to use.
>
> Have you any pointers to best practices on *testing* new recipes? I don't
> really want to set up a whole dev/test environment just for developing and
> testing each recipe change - it would be too cumbersome. But equally I don't
> want invalid recipes being pushed out, or worse, ones which destroy data.

Testing recipes without taking the actions described is basically an
impossible task to get 100% correct.  You can do dry runs, but any
time you check the run-time state of the system and that state could
have been modified previously in the run, you're going to get a false
positive.

We've been working on ways to let you write real integration tests,
which would go a long way towards allowing you to do real testing in a
VM.  As it stands, the best practice is to have a staging environment
that gets your new changes first, and only prop changes to production
when you are comfortable.

vmware has been really helpful to me here.

Ditto. 

Our chef setup and workflow at Fotopedia is basically the following:

- the production grid is 100% chef-managed, on several instances with some servers having the same role for scalability/redundancy.

- the testing grid is very similar, with a lower instance count as scalability/redundancy is not a problem

- everybody in the team runs an "infrabox" which is basically the whole infrastructure stack running in a VMWare instance. This is useful both for regular development of bits and pieces of our app, and chef/infrastructure work

  - when running in infrabox, the cookbooks attributes are slightly tweaked (avoid port conflicts, development mode for some components, some coobooks omitted). Some components are checked out by chef as in the testing/prod grids (through chef-deploy), and some can be manually switched to a shared folder for manual control (and textmate editing :) ). Ditto for chef cookbooks (edited on the mac, tested on the VM).

  - changing things in chef on the infrabox is the first level of testing/dev, after we check it's working on the testing grid in real multi-server mode and then prod.

We might write a blog post about this some day (but we first need to update our 0.6 setup to 0.7).

Ol.

-- 

Fotonauts

Director, Server Software