Chef-solo or Chef-client for local testing

Hi,

I wanted to get folks opinions on what is better to use for local
infrastructure development chef-solo or chef-client?

I’m thinking it is nice to be able to have a fully isolated environment using
chef-solo locally with say a Vagrant box or any other vm offering of your
choice. The reason I say this is if you had all your developers using the same
production chef-server and same environment that there is a chance that you
could all stomp on each others toes. I know you can freeze the version but now
I have to keep maintaining my version list locally which I feel could be a
maintenance nightmare if you have a lot of cookbooks. My thought is you would
use chef-solo for local development and then after you commit your changes it
goes to a continuous integration environment where chef-client is used. In the
continuous integration environment it could use environment=development and
that environment could specify what version to use. After it has successfully
been tested in the continuous integration environment the production
environment file then gets a bump to use the new version that was just tested.
Anyone see any holes in this process or have any suggestions for a better
approach? If you think chef-client would be a better choice for local dev can
you offer up some ideas on how it would work with multiple users?

Looking forward to your responses.

I also have this question posted here:
https://groups.google.com/d/topic/chef-testing/3qZfJqOsycU/discussion

Thanks,
Jay

Hi Jay-

On Thu, Apr 12, 2012 at 05:43:54AM -0700, bosoxjay@gmail.com wrote:

I'm thinking it is nice to be able to have a fully isolated environment using
chef-solo locally with say a Vagrant box or any other vm offering of your
choice. The reason I say this is if you had all your developers using the same
production chef-server and same environment that there is a chance that you
could all stomp on each others toes. I know you can freeze the version but now
I have to keep maintaining my version list locally which I feel could be a
maintenance nightmare if you have a lot of cookbooks. My thought is you would
use chef-solo for local development and then after you commit your changes it
goes to a continuous integration environment where chef-client is used. In the
continuous integration environment it could use environment=development and
that environment could specify what version to use. After it has successfully
been tested in the continuous integration environment the production
environment file then gets a bump to use the new version that was just tested.
Anyone see any holes in this process or have any suggestions for a better
approach? If you think chef-client would be a better choice for local dev can
you offer up some ideas on how it would work with multiple users?

You probably need both -- if you use features chef-solo doesn't provide in
production, I bet you want to test them, too. We use chef-solo while iterating
on cookbooks and to sanity-check proposed changes later in their life, but we
still want to test interactions between the client and server. We don't have an
automated workflow to capture the above yet, but it's on the list.

--

Will Maier