linusthe3rd's questions

I am wondering how projects that have multiple component teams manage their sets of cookbooks?

We are trying to figure out how we can have an ops team provide a set of "common component" cookbooks that can be re-used by other teams that will also write their own cookbooks. For example, the ops team should own the Java cookbook, while a component manages their cookbooks written for their component or build engines.

From my little experience with chef server, this kind of workflow seems to not be well supported since the server stores and manages all cookbooks - so there is a potential to overwrite a cookbook written by another team.

How do other projects deal with this type of problem?

My team has created a large number of chef cookbooks. I was wondering what methods and frameworks I should look into so we can start creating tests to assure that our nodes are configured properly?

I am looking at automated deployment solutions for my team and have been playing with Chef for the past few days. I've been able to get a simple web app up an running from a base Red Hat VM using chef-solo.

Our end goal is to use Chef (or another system) to automatically deploy application topologies to the cloud as we run builds. Our process would basically run like this:

1. Our web app code, dependencies, and chef cookbooks are stored in SCM
2. A build is executed and creates a single package for images to acquire and test against
3. The build engine then deploys new cloud images that run a chef client to get packages installed.
4. The images acquire the cookbooks from SCM or the Chef server and install everything to get up and running

What are the benefits and/or use cases for getting a Chef Server running?

Are there any major benefits to have a Chef Server hold and acquire the cookbooks from SCM vs. using chef-solo and having a script that will pull the cookbooks from SCM?