[Upcoming Release] ChefDK 0.10.0



We’ve got a candidate package of the ChefDK version 0.10.0 ready that we would love for people to use and give feedback on. You can see the full changelog in the pull request but I’ve copied it below for friendliness.

To install this build of the ChefDK you will need to download it from our current channel by following these instructions. The build will still have a version of 0.9.0 because the PR containing the version change hasn’t been merged yet, but it contains all the code changes for 0.10.0.


Release notes (from RELEASE_NOTES.md):

ChefDK 0.10.0 Release notes

Updated Dependencies

  • knife-windows - updated to 1.1.1 (see below)
  • chef-provisioning - updated to 1.5.0
  • chef-provisioning-aws - updated to 1.6.0

knife-windows Enhancements

This release of the ChefDK ships with Knife-Windows 1.1.1 and marks the first v1 release to be bundled with ChefDK. Full details of features included in both 1.0.0 and 1.1.0 can be found in the release notes here:

For those who make use of Knife-Windows in your day to day Chef development workflow, here are the breaking changes and highlights:

Breaking changes

  • Negotiate is the default authentication protocol - Prior to this release, the default authentication protocol depended on the format of the --winrm-user option. The basic authentication protocol would be assumed unless that option had the format domain\user. To revert to the behavior of previous releases or otherwise force knife-windows to use a specific authentication protocol such as basic, use the --winrm-authentication-protocol option.
  • Default WinRM port depends on the transport - The default port is still 5985 for non-ssl connections, but now defaults to 5986 if you’re using ssl.
  • Kerberos Keytab short option is now -T to fix a conflict with the --identity-file option.

Making it easier to setup WinRM over SSL

Setting up WinRM communication over SSL can be far from straight forward. Certificates need to be configured on both ends, firewall rules must be added and a WinRM listener has to be created. This Knife-Windows release adds some new knife commands to help automate these tasks:

  • knife windows cert generate generates a certificate and related public key file for use in configuring a WinRM listener and validating communication
  • knife windows cert install installs a certificate such as one generated by the cert generate subcommand into the Windows certificate store
  • knife windows listener create creates a WinRM SSL listener on a Windows system

Validating WinRM Configuration

A new subcommand: knife wsman test verifies winrm functionality on a remote system.

New Bootstrap Options

  • --hint creates Ohai hints on bootstrap
  • --bootstrap-install-command allows an alternate command to be used to install Chef Client
  • --install-as-service will have Chef Client be installed as a Windows service on bootstrap
  • --msi_url provides an alternate URL to the Chef Client installation package

Validatorless bootstrapping

Look mom, no validator! Thats right - as seen in the core chef client first, this is now possible in knife windows bootstrap as well.

Proxy support for WinRM

The knife winrm and knife bootstrap windows winrm subcommands now honor the proxy server configured via the http_proxy setting in knife.rb for WinRM traffic.

chef generate commands now default to using Berksfile instead of Policyfile

In ChefDK 0.9.0, we changed the defaults for chef generate cookbook to create Policyfiles instead of Berksfiles. Our training materials and tutorials were not updated to account for this change, so we’ve changed the behavior back. You can still generate cookbooks with Policyfiles by passing the -P option to chef generate cookbook.

Additionally, you can generate a Chef repo with appropriate directories for Policyfiles by running chef generate repo -P.


There is 1 more update to the upcoming 0.10.0 release to include - Inspec and Kitchen-Inspec! I’ve updated the RELEASE_NOTES.md in https://github.com/chef/chef-dk/pull/585 but here are the notes for the Inspec inclusion:


Chef Inspec was released November 3rd. We’re now packaging this tool into the ChefDK. The Github README has an overview of the project and the developers posted an informative blog as well.

The primary means of interfacing with Inspec is through its command line tool inspec. The most important thing to note about the integration with the ChefDK right now is that the inspec tool is not added to your PATH by default when installing the ChefDK. To leverage it you can either

  1. Prepend all your inspec invocations with chef exec. For example, following their guide you would run chef exec inspec exec test.rb to run local Inspec tests.
  2. Add the executable to your PATH manually. On linux/OSX systems this is located at /opt/chefdk/embedded/bin and on Windows it is located at C:\opscode\chefdk\embedded\bin.

This path change is temporary - we plan to include inspec in the PATH by default in future ChefDK releases.


Kitchen-Inspec is a new Test Kitchen verifier that leverages Inspec. This verifier is only compatiable with Test Kitchen version 1.4 or greater, and will only work with other Test Kitchen plugins that also leverage Test Kitchen 1.4. Some examples of drivers which leverage Test Kitchen 1.4 are the Vagrant plugin and EC2 plugin.

Look at the .kitchen.yml and tests in the Inspec example of what a cookbook leveraging Inspec should look like.

The advantage of using this is that the Inspec verifier executes locally on the target node, instead of executing remotely from the node running Test Kitchen. This should reduce test times. It also leverages the advanced auditing and compliance features that Inspec exposes.