Release: Chef Development Kit 0.2.1

Ohai Chefs,

As of today version 0.2.1 of Chef Development Kit is available on our download page. Starting with this version, Chef Development Kit is now supported on Mac OS X 10.8 in addition to 10.9.

The other changes included in this release are:

  • chef gem install can now install gems with native extensions on Windows.
  • Fixed a bug in chef exec to set the ENV correctly. This resolves errors like this when running commands with chef exec.
  • Make supermarket the default source in generated Gemfiles.
  • chef generate repo command is now available. This command generates a chef repository which is equivalent to chef-repo.
  • Generators do not require Administrator privileges on Windows anymore.

You can visit to get this version. If you run into any issues please file a bug in our issue tracker.

Behaving Responsibly in the Chef Community

Today one of our most prolific community members announced his decision to leave Chef and go on a software engineering sabbatical, in part because of how he was treated by a few members in our community. As a company, Chef takes the safety and security of our employees extremely seriously. Further, it is our heartfelt desire to have a community where diverse opinion is welcome and where members feel safe and secure to engage in healthy, and sometimes spirited, dialog with the mutual goal of creating value and growing as professionals and human beings. As a community, we need to use this event as a moment to reflect on how we treat each other.

De-humanizing the authors of software

It is easy to anthropomorphize software and praise it when things go well and curse or even hate it when things do not. In open source projects it’s easy to identify the authors and maintainers of a particular software project and direct your feelings about the software towards those individuals. Likewise it is easy for the individuals who see comments made in public forums such as twitter, mailing lists, and GitHub to take these comments very personally.

Often times, the most prolific contributors are very dedicated and, as a result, can be very opinionated and passionate about their projects. This dedication and passion are, in fact, characteristics of many great engineers. At times, these very same characteristics can make these people targets of misguided rage, anger, and hurtful words and actions. It is sad to see a talented and passionate member of our community make the decision to leave as a result of how they were treated. We, the collective individuals that make up the Chef Community, should take this opportunity to reflect on how we treat one another and on how we can use the power of the community to lift people up rather than tear them down. And at the same time, we should also consider how diversity in opinion and style can make us all stronger and better.

The Chef Community

The Chef community is a mixture of professionals and volunteers who come from all over the world and work together to make Chef better, including mentoring, teaching, and connecting with other members of the community. Diversity is one of our biggest strengths, but it can also bring increased communication challenges at times.

As a community member, you know that the Chef community is an environment built on generosity, professionalism, friendship, and hugs. As a result, we’ve adopted and published a set of community guidelines.

As a company, Chef stands behind and helps enforce these community guidelines. As a community, we must be ever vigilant of our guidelines and ensure that they are comprehensive and supportive of our diverse community.

Behavior that violates these guidelines is unacceptable and should and will not be tolerated by anyone in our community nor by Chef.

We are reviewing and enhancing these guidelines right now as part of our ongoing efforts to improve the Chef Community. Going forward, our community guidelines will include a clear path for handling incidents and a discussion on the actions that will be taken when someone violates our guidelines. Specifically, our guidelines must:

  • Outline actions that will result in punitive action
  • Indicate who is responsible for determining when punitive action is warranted
  • Specify punitive actions and an appeals process

The code of conduct we use for #ChefConf is explicit about these things and will inform the new guidelines.

Committed to the Community

Chef takes allegations of misconduct very seriously and will investigate and address each incident. As a community, we are refining our policies and procedures for upholding our community guidelines.

Behavior outside of our community guidelines is unacceptable and should and will not be tolerated by anyone. If you encounter such behavior, please contact a member of the Chef community team immediately.

Next Steps

Thank you for participating in these conversations. Here are some immediate actions you can take to help us improve the community.

  1. Behave responsibly and help us address unacceptable behavior when it occurs.
  2. Participate in the RFC to rewrite our community guidelines.
  3. Join us at the next Chef Developers’ IRC Meeting to discuss the RFC.
  4. Join us at one of our upcoming Chef Community Summit events to discuss this topic in person with other community members.

Thank you for helping our community grow and evolve.

Nathen and Adam

Serving Up Delight at the Community Summits

We are excited to announce this year’s Chef Community Summits! The Chef Community Summit is a a unique opportunity for open-source contributors, Chef engineers, and Chef users of all experience levels to come together and share their passion and excitement for Chef.

This intimate gathering of enthusiasts is facilitated as an Open Space event. Participants of the Summit will propose topics, organize an agenda, and meet to discuss and work on the ideas that are most important to the community.

This year we’ll be hosting Community Summits in both Seattle and London

Some likely topics include:

  • What is the roadmap for Chef?
  • What best practices have emerged & how should we share them?
  • How will our community grow while serving experts & welcoming newcomers?
  • What should #ChefConf & other events in 2015 cover?
  • Additional topic ideas are being proposed on the Chef Community Wiki.

Seattle – October 2-3

London – October 15-16

Limited sponsorship opportunities are available for the Seattle Chef Community Summit checkout the sponsorship prospectus for additional details.

See you in Seattle and London!


This was originally posted on

An email recently came across one of the mailing lists I subscribe to. I wanted to share my answer here, because this is an important discussion.

Is DSC for Setup or Management?

Yes (notice, it’s not an XOR)

In my opinion, DSC (and Chef) is for setup and the management of the structural configuration of the system. To directly address some of the questioners initial points:
Do I need to develop custom DSC resources (for example to create DFS folders and links) and apply a new configuration each time I have to create/or modify a DFS link? Or should I stick to the traditional system administration (I mean using PowerShell cmdlets or the GUI)?
Well, currently you’d have to implement a custom resource for DFS shares, but you don’t need a custom resource per share. You would need to modify your configuration to add a new share, but modifying a configuration should be almost a non-event.

These Aren’t Your Grandma’s Shell Scripts

If you buy into the Configuration-As-Code or Infrastructure-As-Code concept, one of the first things you want to tackle is building a pipeline to deliver those configurations to your servers. Whether you use a pull server setup (my preference) or you push configurations out to individual nodes, having a solid delivery mechanism makes changing configurations not much more difficult than editing a file and checking into source control (which is way easier than the “traditional” approach). Setting up this pipeline IS work on the front end, but pays dividends in your ongoing maintenance of your environment.
I realize that it could be tempting to use DSC as a management system, but I think it is not a good use of DSC at all (please correct me if I’m wrong). Indeed, in order to manage a computer you have to modify (and reapply) the current config of the machine and that may take more time than using the usual cmdlets to get the work done.
If you are spending more time modifying the configuration (once you have resources and pipeline in place) than it would take to configure it on a server or series of servers, we need to sit down and have a chat. Yes, building a resource takes time.

Setting up a test environment takes time.

Structuring your configuration data takes time.

Building a deployment pipeline takes time.

It seems like a lot of time, when you could just RDP over the box.. or even quicker, use PowerShell remoting or some CIM cmdlets right at the box. But so does interactively managing each of your servers.

Over time, interactively managing (and rebuilding, and testing when the next OS ships) tends to take way more time than if you invest in your configuration testing and deployment process. That’s one of the advantages to the Chef ecosystem.. there’s a great testing platform, which is being rev’d to make Windows testing easier (and supports DSC via the Chef DSC integration, and hopefully as a native provisioner in the near future).

But DSC will solve my DR problem though, right?

But if I stick to the good old traditional system admin what if my server crashes? Well, I’ll need to restore my machine as usual. That being said (please react to this), in a DSC world – where I would have managed my server by reapplying a new config after each creation of DFS link (for example) – in case of crash I would only have to apply the configuration to a (bare) new machine right? This way, in a few minutes I get a fresh up and running machine with the DFS role installed AND all the configuration (DFS links recreated, etc.). Am I right???
Exactly. One of the benefits of using a declarative configuration management system is that you can more easily recreate the infrastructure that hosts a particular service.

But it is more than DR

This isn’t just a DR thing. Now that Microsoft is picking up the cadence of OS releases, that means the support cycle is tightening.

Remember the whole N-2 support for management tooling? When releases were 3 years apart, that gave you 9 years to stay current if you installed the latest release. When the release cycle is more 12 to 18 months, then you are down to 2 to 4.5 years for backward compatibility in management tooling. That means, to stay current, we have to be able to cycle to new server platforms faster.

The patching story is changing as well. Now there are servicing points you have to hit to continue to get patches (that’s the whole story behind the “with Update” thing and why the Server 2012 R2 image on MSDN was updated to “with Update”). That was roughly 6 months after the OS went Generally Available? How quickly can you get your environment up in a test lab to test those updates? With declarative configuration management, just supply some different environmental data, and you can stand up near clones of your production environment for testing.

Remember when I said SysAdmins could pull some good ideas from Development?

We need tools to help shorten the cycle in which we can deploy new operating systems and keep things patched. These tools exist – DSC, Chef, Test-Kitchen, ServerSpec, Vagrant, GuardRail, and more. These tools give us the ability to rapidly develop new resources and to build an automated pipeline that can deliver tested, high quality configurations to our servers.

We can leverage the concepts in Continuous Delivery to improve our ability to deal with infrastructure changes.

  • Automate all the tests we can.
  • Assume people checking in changes are professionals and optimize the pipeline for success.
  • Don’t leave the pipeline in a broken state.
  • Don’t be afraid to “Roll Forward” and fix things that break (vs. looking to roll back).

What would you say if you could have a process that, once patches came out on Patch Tuesday, that a process kicked off spinning up a test version of your environment, applied a patch at a time, ran smoke tests, and at the end you got a report of any breakages, and which patch things broke on? That’d be awesome and is totally achievable.

Don’t get laughed at

When human beings do things that the computers are perfectly capable of… Late at night the computers get together and laugh at us – Neal Ford
We need to move away from manually implementing changes and manually checking changes and put automaton in place that does these standard, repeatable tasks and save the humans for the interesting, challenging work that we are better at.

Chef demonstrates vCloud Air integration at VMworld 2014

We’re pumped for VMworld this week, especially because our own Matt Ray is taking part in a cool joint demo with our friends at VMware. Tomorrow (8/26) at 4 pm PT, Matt is joining Jay Marshall from VMware in demonstrating Chef’s ability to automate the management and migration of enterprise workloads in both vSphere and vCloud Air environments.

Here’s an excerpt from the abstract:

“…Achieving infrastructure portability and harnessing the benefits of continuous delivery remain an elusive goal for too many users. VMware’s Jay Marshall and Chef’s Matt Ray share the stage to illustrate how to architect a multi-node application using Chef, and then deploy that application to vCloud Hybrid Service to simulate a test/dev sandbox in the cloud. That exact same Chef cookbook will then be used to deploy the application into Production in an on-premises vSphere environment… In the end, attendees will walk away with working knowledge of how to provide their developers and operators with a cloud-based Test/Dev environment on vCloud Hybrid Service instrumented with Chef, while still maintaining production SLAs and control over their Production workloads.”.

In other words, Matt and Jay will show how Chef and vCloud Air give you the ability to speed software and service delivery using a single platform for automating both virtualized and hybrid cloud environments.

In addition to Matt and Jay’s session, VMware vice president of Hybrid Services, Ajay Patel, will be introducing vCloud Air at VMworld during a breakout session today at 12:30 pm PT, where he will detail the roadmap for this new platform.

When you’re not checking out these sessions, please stop by our booth # 2346 for a Chef Tee, swag, and a chat with one of the many Chefs on-site.

Learn how Scholastic migrated to AWS with Chef automation

Daryn McCool was nice enough to share the story of Scholastic’s major IT modernization initiative with us. It was a great opportunity to have an enterprise customer walk through their journey to the cloud.

If you are considering an IT modernization project or looking for best practices in the community, I’d recommend watching the webinar.

A few themes stood out: Read more ›

On Joining Chef

As many of you in the Community have seen by now, I recently joined Chef as a Vice President (more on what in particular I will be up to in a minute).

I first came across the open source Chef project while working at ThoughtWorks, where we got to experiment with various new technologies in order to find the best solutions to solve our customers’ problems. Chef began to crop up more and more frequently in our internal discussions of which tools had been effective, and I was sufficiently impressed that it got a few mentions in the Continuous Delivery book that Dave Farley and I published in 2010.

Four years later, Chef — both the product and the company — is going from strength to strength. I have seen many companies use Chef’s platform to enable their move to continuous delivery, and I’m excited about our plans for the future. I am delighted to have the chance to be part of its evolution and growth — and to count among my colleagues some of the people I admire most in our community.

Now back to what I’ll be doing. My focus will be to grow a high velocity organization that delivers the most awesome customer experience in the industry. Organizational culture and development are topics that form the core of my forthcoming book, Lean Enterprise, and I am super excited that Chef has asked me to be part of further developing their high performance culture.

I’ll be writing periodic updates both here and at You can also follow my progress on Twitter — and I’m hoping to make it to as many Chef community events as I can, starting with FlowCon in San Francisco.

Jez Humble Joins Chef as Vice President of Development Velocity

Continuous Delivery Pioneer to Play Leadership Role at Chef as Enterprise DevOps Adoption Surges

SEATTLE – August 20, 2014 – Chef, the leader in web-scale IT automation, today announced Jez Humble has joined the company as vice president of development velocity. Humble is the co-author of the highly influential book Continuous Delivery:Reliable Software Releases through Build, Test, and Deployment Automation. A noted speaker and lecturer at the University of California, Berkeley, Humble is widely regarded as one of the premier leaders in agile software delivery practices and the implementation of positive organizational change. At Chef, Humble will play a leadership role in shaping Chef’s own engineering processes and will guide Chef’s continuous delivery solutions strategy amidst surging enterprise DevOps adoption.

Read more ›

Release: Chef Client 10.34.0 & Ohai 6.24.0

Ohai chefs,

Today we have released Chef Client 10.34.0 and Ohai 6.24.0. These releases contain important bug fixes and improvements that has been blockers to the Chef users who are on Chef 10.

The MVP of this release is again Phil Dibowitz. Thanks Phil for your continuous support to us while maintaining Chef 10.

Here is the full list of changes in these releases:

Chef Client 10.34.0

  • Phil Dibowitz: ‘group’ provider on OSX properly uses ‘dscl’ to determine existing groups
  • options attribute of mount resource now supports lazy evaluation. (CHEF-5163)
  • Fix OS X service provider actions that don’t require the service label to work when there is no plist. (backport CHEF-5223)
  • Set Net::HTTP open_timeout. (backport CHEF-1585)
  • Fix RPM package version detection (backport Issue 1554)
  • Support for single letter environments.
  • Add password setting support for Mac 10.7, 10.8 and 10.9 to the dscl user provider.

Ohai 6.24.0

  • Phil Dibowitz: linux::filesystem now reads all of /proc/mounts instead of just 4K
  • Phil Dibowitz: Use lsblk instead of blkid if available.
  • Phil Dibowitz: linux::network should handle ECMP routes


We have had some conversations about the supported Chef versions in the approaching major release Chef 12 with our community. As a result, we’ve decided to drop support for Chef Client 10 this October when Chef Client 12 ships.

We will continue to ship Chef Client 10 with contributions and required security fixes until 12/31/2014. If you want to get more information about this and Chef 12 check out the recently approved Chef RFC here.

How to get it?

As usual you can get this release with our install script on non-windows platforms:

curl -L | sudo bash -s -- -v 10.34.0

You can check out our install page for more options or download this release for Windows using this link:

Chef Client 10.34.0 Windows MSI

If you have any problems with this release, you can file an issue at GitHub.

Webinar: Migrating Enterprise IT to AWS

Here at Chef we have the privilege to share all kinds of innovation, community news and compelling events with you via the blog. I’m particularly happy to invite you to a webinar we’re hosting this week with Scholastic. If you are actively transitioning your IT or Dev organization (or just planning) come find out how this nearly 100 year old publishing company has accomplished their own modernization initiative with automation and cloud.

Daryn McCool, an IT leader with Scholastic will walk us through how they approached their transition to AWS. Join Daryn, me and Chris Munns from AWS as we cover key considerations, including:

    • Legacy workload migration and architecture
    • Security in public IaaS
    • Agility & Elasticity improvements
    • Culture change in IT
    • Introducing new Dev Tooling
    • Cloud costs and accounting
Please join us Thursday by registering here.