Today, we are excited to announce the availability of Chef Client 12.0.0 which complements [Chef Server 12](https://www.getchef.com/blog/2014/11/25/chef-server-12-released/). This version introduces numerous improvements to Chef Client while retaining backwards compatibility with current versions of Chef Client and Chef Server.
This release wouldn’t be possible without the help of Chef community along the way. We have around 70 contributions in this release. Among these [Jesse Hu](https://github.com/jessehu) and [Sander van Harmelen](https://github.com/svanharmelen) made a huge impact to Chef community with their contributions.
Jesse’s [investigation and patch](https://github.com/opscode/chef/issues/1904) helped us to quickly resolve an issue which caused Chef Client run failures against Chef Servers that are under heavy load. Sander tracked down [a really tough bug](https://github.com/opscode/chef/pull/1827) in core REST libraries and he bore with us to find the correct solution to the problem. Congratulations Jesse and Sander. You are the MVPs of 12.0.0!
## What’s New
### Backwards Compatibility
Before talking about what is new, a boring but important item. In order to ensure a frictionless migration, Chef Client 12.0.0 is fully backwards compatible with Chef Client 11. You can migrate to this version using your existing cookbooks, custom plugins & handlers that work with Chef Client 11.
You can use Chef Client 12.0.0 against with any version of Chef Server (Enterprise Chef Server, Open Source Chef Server or Hosted Chef Server) including Chef Server 12. One small note. If you are using Enterprise Chef Server with a version earlier than 11.2.5, make sure you update `chef_max_version` configuration. Here are the instructions:
1. Add `lb[‘chef_max_version’] = 12` to your `private-chef.rb`
1. Run `sudo private-chef-ctl reconfigure`
### AIX Support
With Chef Client 12.0.0 we are proud to announce official support for AIX 6.1 and 7.1 on the IBM POWER platform. Chef’s own [Julian Dunn](https://github.com/juliandunn) and [Scott Hain](https://github.com/scotthain) will have a blog post very soon about this functionality.
### Windows Performance Improvements
We have been continuing to make major investments to bring the Windows experience on par with Linux experience. With Chef Client 12 we have some exciting news for Chef users on Windows.
One of the major pain points for Chef on Windows has been performance. With Chef Client 12 we have increased the performance of our tools across the board. In Chef Client 11, anytime you run `chef-client` or `knife`, the CPU utilization of the box has temporarily spiked up to 100%. We have fixed this in Chef Client 12 with two new features:
1. We have bumped the Ruby version that ships in our packages to Ruby 2.0.0 which is orders of magnitude faster than Ruby 1.9 on the `require` path. Since chef requires a high number of gems, this update decreased our initial load times and fixed the initial CPU spike when running our tools.
2. Chef Client 12 now uses [appbundler](https://github.com/opscode/appbundler) a tool that we have been using for Chef Development Kit. Appbundler makes sure that the version dependency resolution for the gems we use is calculated before hand in order to further decrease our the initial load times.
**Note:** `appbundler` is enabled not only of Windows but for all platforms. So this change improves the performance of Chef Client across all platforms.
### Windows Event Logs
In addition to performance improvements we have continued to improve our integration with native Windows features. One big step in this direction was to start logging events into Windows Event Logs which is the common location for Windows administrators to check events happening on the system. Chef Client 12.0.0 now logs some basic events (Run Start – Run Success – Run Failure) to the `Application` event logs on Windows nodes.
### Secure by default with SSL verification
In order to provide out of the box security, SSL verification is enabled by default in Chef Client 12.0.0. With this change Chef Client will verify SSL certificates of remote servers when talking to them over HTTPS. Bootstrap code path is updated to move the trusted certificates to the newly provisioned nodes. In case of any issues, you can use `knife ssl check` to diagnose the issue. For the existing nodes `knife ssl fetch` is available to acquire the missing certificates.
### Built in partial search for knife and recipes
Many of the members of the Chef community have been enjoying the benefits of [partial search cookbook](https://github.com/opscode-cookbooks/partial_search) for a while. Partial search enables filtering the output of search based on a given pattern. With Chef Client 12.0.0 this functionality is now moved into Chef Client.
This logic is available with `:filter_result` argument for `search()` inside the recipes and with `–filter-result` CLI option for `knife search`.
### Dynamic Provider Resolver
One of the architectural problems of the resource / provider infrastructure in Chef has been the static mapping between resources and providers based on platforms. This problem was amplified in cases where more than one provider can be available for a resource on a given platform. Ubuntu 14.04 is a good example. In order to manage a service, one needs to correctly specify either the Debian (SysV) or Upstart providers. With Chef 12 the `ProviderResolver` is smart enough to figure out which provider to use based on the init scripts that it finds.
The `ProviderResolver` will also use the correct provider based on if it finds systemd enabled as the init system on a distro. This means that nodes which normally do not have systemd installed will use the systemd provider if systemd has been installed. Conversely, nodes that have systemd removed on distros which normally support systemd will use the appropriate SysV providers. If recipe code installs or removes systemd then subsequent service providers will dynamically switch to the correct provider.
The resolution of resources has also been made more dynamic across the board. Now on Ubuntu when installing a package we will use a `Chef::Resource::DpkgPackage` resource and on RHEL distros we will use a `Chef::Resource::YumPackage` resource which will get the options validation correct.
### New functionality in Chef Client 12.0.0 Attributes
With the help of [Phil Dibowitz](https://github.com/jaymzh), [Chef RFC 23](https://github.com/opscode/chef-rfc/blob/master/rfc023-chef-12-attributes-changes.md) is implemented in Chef Client 12.0.0. This change adds the ability to:
* Be able to safely delete a key in the attributes tree at a given precedence level.
* To be able to safely delete a key in the attributes tree at all precedence levels
* To be able to set a value at a precedence level in a way that overwrites the entire nested value of a key at that precedence level.
Again it is important to call out that these changes retain full backwards compatibility except a minor case. `node.force_default!` and `node.force_override!` have changed from accessors to setters, and any cookbook code that used these functions
(extremely uncommon) simply needs to drop the exclamation point off of the method
### Mac OSX Improvements
With Chef Client 12.0.0 we will drop support for Mac OSX 10.6 & 10.7 and add support for 10.10. In addition to this we have a bouquet of improvement for Mac OSX in this version.
Previous versions of Chef used to do package management using macports. Our awesome community built a cookbook that enabled more reliable and easier package management using homebrew. Thanks to [Joshua Timberman](https://github.com/jtimberman) this logic is now part of Chef core.
With 12.0.0, Chef can now be used to reliably manage the users on Mac OSX. User passwords can be set either by plain text or using the SALTED-SHA512-PBKDF2 style shadow hashes used by Mac OSX 10.8 and above.
Group provider also got a fleet of bug fixes which improved the reliability and idempotence.
### File Specificity Overhaul
[Noah Kantrowitz](https://github.com/coderanger) implemented [Chef RFC 17 – File Specificity Overhaul](https://github.com/opscode/chef-rfc/blob/master/rfc017-file-specificity.md) in Chef Client 12.0.0. With this RFC it is now possible to omit the enforced cookbook folder structure while creating templates or cookbook files. It is now possible to set search paths for the files directly on Chef resources.
### Usability Improvements
One of the efforts of this release was to make the minor changes that we were not able to do due semantic versioning constraints. Since this is a major version bump, we were able to make some minor changes to the API that makes the Chef experience more delightful. Here are some highlights from these changes:
* Command line options cleanup of `knife bootstrap`
* Auto magical encryption / decryption of encrypted data bags in recipes and via knife.
* Making `shell_out` function available in the recipe DSL to make command execution simpler.
* Disabling lazy cookbook synchronization by default to avoid token issues in long Chef runs.
* Staging the temporary files in destination directory by default in order to avoid problems when `/tmp` is on a separate disk.
* Enabling client side key generation by default to increase scalability while bootstrapping high number of nodes at the same time.
* Evaluating guards with parent resource type and inheriting attributes from it by default to reduce the coding while typing a `:powershell_script` or `:batch` resource.
## What else?
You can find more details on these changes and more in [12.0.0 Release Notes](http://docs.getchef.com/release/12-0/release_notes.html) and see the full list of changes in [12.0.0 CHANGELOG](https://github.com/opscode/chef/blob/12-stable/CHANGELOG.md).
## How to get it?
You can visit our [download page](https://www.getchef.com/download-chef-client/).
Additionally you can use this command to download the latest version of the Chef Client on platforms other than windows:
curl -L https://www.getchef.com/chef/install.sh | sudo bash -s — -v 12.0.0
For Windows, you can download this version using this link: [Chef Client 12.0.0 Windows MSI](https://opscode-omnibus-packages.s3.amazonaws.com/windows/2008r2/x86_64/chef-client-12.0.0-1.msi)
## Get Help
We are here to make sure that you have an easy transition path to Chef 12. If you run into any issues with this version just reach out to us and we will be waiting to help out.
You can reach us by [filing an issue at GitHub](http://www.github.com/opscode/chef/issues/new) or dropping an email to our [chef](http://lists.opscode.com/sympa/info/chef) and [chef-dev](http://lists.opscode.com/sympa/info/chef-dev) mailing lists.
Thanks for making Chef better for all!
## Known Issues
This section contains information about the known issues migrating from Chef Client 11 to Chef Client 12.
### Unsigned rpm packages
The released Chef Client 12.0.0 rpms were inadvertently not signed. This issue doesn’t prevent installation of Chef Client 12 from omnitruck (our package distribution endpoint) however it blocks installation if the package is distributed via an internal yum repository. We are working on this issue and will update this post when we got the issue fixed.
### NoMethodError: undefined method `directory’ in lvm cookbook
In Chef Client 11 we had the recipe DSL included in the `Provider` base class. This logic belongs to `LWRPBase` class so for clean up we’ve removed it from `Provider` base class in Chef 12. This change created an issue in lvm cookbook since it has a heavy weight provider that uses the directory resource directly. The workaround is to inherit from `LWRPBase` rather than `Provider` class in order to be able to resources directory in custom resources. We will update our documentation to reflect this change.
### NoMethodError: undefined method `path’ in the execute resource
In Chef Client 11 we had a `path` attribute for the execute resource but it was not honored by the provider and was not being used. For cleanup we’ve removed this in Chef 12. This change made Chef Client to raise an error rather than accepting and not using it, when `path` attribute is used in execute resource. Workaround is to use `environment` attribute to set `PATH` in the execute resource.