Original Post from OpsCode: http://www.opscode.com/blog/
We’ve got a bundle of exciting Chef news for you today.
- Chef 11.6.0 release
- Ohai 6.18.0 release
- Client release cadence
- Testing matrices
Opscode is excited to announce the release of version 11.6.0 of the Chef client. You can download the installation packages from the install page now.
- The file resource and provider, as well as the subclasses such as cookbook_file and template, have been significantly refactored.
- Added atomic updates
- Simplified code
- Base SELinux support
- Conditional GETs (ETags)
- ftp and local file copy
- Ruby is upgraded to 1.9.3-p448 to include the OpenSSL security fix (CVE-2013-4073)
- Template helper methods
- Daemonized chef-client now defaults to forking on Linux/Unix.
- The batch and powershell_script resources from the windows cookbook are now in core Chef.
- Initial Ruby/rubygems 2.0 support (when testing under a gem based install)
- Encrypted data bag items now support authenticated encryption
- Node objects are now sortable
- Native support for running the Chef client as a service on Windows
- CA certificates are now included in the Omnibus packaging
For more information, check out the full release notes.
As usual, we had a huge number of contributions from the Chef community:
Jesse Campbell spear-headed many of the file resource and provider related tickets and was a big part of all the refactor work. Thanks Jesse! You’re this release’s MVP!
Xabier de Zuazo past double-MVP, provided many patches. He fixed bugs in ‘knife cookbook site share’ and ‘knife cookbook test’, added support for debian and Ubuntu to the ifconfig resource, silenced some EPIPE errors, fixed bugs in the route provider, raise the precedence of not_if/only_if in the resource, and added support for new conditionals when comparing platform versions
Ranjib Dey improved the knife -a flag to support returning multiple attributes, added GCEL platform support, and cleaned up the spec tests
Ionuț Arțăriși ported the zypper provider to shellout so command output would be captured, enabled gpg checks in zypper, and fixed a bug in the group provider on openSuSE 12.3
Yoni Yalovitsky fixed a bug preventing the path to config files from showing up in exceptions, and improved an unhelpful error that occurred when log_location was not writable
Teemu Matilainen added support for chained lazy-loaded dependencies in knife, updated the omnibus bootstrap template to use SSL, and cleaned up some really old Chef::Config default values that are no longer used
Chris Roberts provided a patch that allows passing Procs as attribute values
Ben Bytheway updated the embedded ruby to 1.9.3-p429 to include significant Windows performance improvements
Felix Bünemann improved cross-platform support for chef-solo in the cookbook tarball unpacking code
Jon Morrow cleaned up on old monkey-patch to Dir
Jessica Bourne ensured that the user_valid_regex check supported Windows usernames
Phil Dibowitz improved the yum package provider and added support for a timeout
Steffen Gebert updated the git provider to run a submodule sync when using submodules
Eric Saxby fixed changing a user’s groups on SmartOS
Kyle Goodwin added support for enviroments in chef-solo
Matthew Horan made the client finish up before exiting on TERM
Loic Antoine-Gombeaud improved messaging in Chef::REST around redirections
Peter Vernigorov tracked down an issue in the error_report error handler
Yukihiko Sawanobori improved the solaris service provider, and brought improvements to the SmartOS package provider across the goal line
Kristian Vlaardingerbroek fixed an issue in the mount provider that prevented it from updating changes mount options, and added support for mounting device symlinks
Daniel Schauenberg cleaned up the extra newlines in the output of knife search
Pawel Kozlowski improved the git provider to support the URL changing
Thom May ensured that knife creates tempfiles with a suffix of .json when editing JSON, and added support for “none” as a mountpoint
Adam Spiers ensured that zypper provider does not block
Jeff Blaine caught an issue where FileEdit would raise an exception if the file existed but was empty
Loic Antoine-Gombeaud cleaned up some dead code in #set_or_return
Mike Fiedler added support for explicitly setting a nodes run list using knife
Sander Botman ensured that knife sub-commands were sorted in the help output
Decklin Foster added ssh authentication forwarding to knife
Greg Thornton made the cookbook syntax checks use chefignore files
JJ Asghar caught a typo in the chef-client output
Grégoire Seux found and fixed an issue where Chef wouldn’t release the lockfile when it timed out on a connection
Hiroaki Nakamura added support for DataBag.list in chef-solo
Kannan Manickam cleaned up duplicate push and << methods in the resource collection
Nicolas Szalay improved the included init scripts for Chef
Brandon Adams no_lazy_load patch is now working
H. “Waldo” G. changed the gemfile to source over SSL
Martin Vidner fixed a bug in the unit tests where a dot-file was not being included
Matthew Kent made Chef not consider a definition in the same file a duplicate
Pavel Valodzka improved the execute resource creates attribute in be relative to the cwd attribute if present
Darren Birkett fixed an inconsistency in the LanguageIncludeRecipe deprecation message
Javier Frias added XenServer platform support
Andrea Campi cleaned up some output in LWRPs related to why_run mode
This Ohai release cleans up some major cloud detection functionality, adds support for a couple of new pieces of data and fixes a couple of bugs. It is primarily a community driven release, so thank you!
Joseph Anthony Pasquale Holsten added a root_group attributes to simplify community cookbooks. Thanks for being such a great community member over the years Joseph. You’re this Ohai release’s MVP!
Mike Javorski added support to the EC2 plugin for handling missing metadata API versions
Chris Roberts added support for detecting Rackspace Cloud through metadata
Sander van Harmelen added XenServer to the ‘rhel’ platform family
Ranjib Dey added support for GCEL
Malte Swart and John Skopis improved the ssh key plugin to collect ECDSA keys
Lann Martin fixed a bug to collect ssh host keys when the path is not specified in the sshd_config file
Yukihiko Sawanobori quieted some output to allow JSON parsing via pipes
Laurent Désarmes fixed ip address detection on vserver guests with /32 addresses
Pete Cheslock fixed Openstack detection in the HP cloud
Tim Smith patched the Rackspace plugin to not provide detection using MAC addresses
Eugene Wood fixed a parsing bug with the -d option
Dmytro Kovalov contributed to a cpu plugin for darwin
- [OHAI-126] – ohai -d option parsing bug?
- [OHAI-387] – The rackspace plugin identifies a server from another provider (OVH) as from rackspace
- [OHAI-425] – Ohai discovery on hp cloud fails (using the openstack plugin)
- [OHAI-426] – IP address not detected for vserver guest
- [OHAI-430] – Linux Mint 14 is detected as Debian
- [OHAI-433] – change log level info to debug at network plugin.
- [OHAI-434] – ec2 metadata is unpopulated / ec2 fetch_metadata loops forever
- [OHAI-442] – Ohai does not detect ssh host keys properly
- [OHAI-445] – Detect ecdsa host key
- [OHAI-455] – ohai leaves zombie processes in it’s wake.
- [OHAI-472] – XenServer is recognized correctly using LSB, but is not assigned to a platform_family.
- [OHAI-489] – GCE plugin breaks EC2 plugin
- [OHAI-490] – root_group plugin hangs chef-client on Windows with large AD installations
- [OHAI-279] – Add a cpu plugin for darwin
- [OHAI-419] – cloud.public_ipv4 attribute is not set for Windows Azure VM’s created using knife azure plugin.
- [OHAI-466] – Detect rackspace via metadata
- [OHAI-428] – provide root_group attribute
- [OHAI-444] – Support Google Compute Engine as a cloud platform
- [OHAI-450] – Recognize GCEL as a platform
Client release cadence
We’ve listened to your suggestions and requests, and we’re moving to a three month release cadence for the client. There will be two months of development followed by one month for the internal testing and release process. This means we will be “freezing” for release at the beginning of the month and will have the release out toward the end of the month. We will still review code and generally help you out during release months, it just won’t get merged until after the release. We’re being careful to not set fixed release dates, because we still want to make the best choices we can for you, like including fixes for critical bugs even after the code freeze. This means we’ll be targeting releases of Chef 10.28.0 in August, 11.8.0 in October, and 10.30.0 in November. We hope this helps you set better expectations around your Chef contributions and deployments!
For this release, we took a step back and looked at our test coverage, and then made a concerted, dedicated effort to shore it up in the ways we felt would have the biggest impact. We thought it might be helpful to share some of the ways in which we’ve tested this release.
Our Continuous Integration infrastructure is running pretty much continuously. You can find the tests that are being run in the chef repository, and here are the platforms and architectures we’re running them on:
- Debian 6 (i686, x86_64)
- Enterprise Linux 5 & 6 (i686, x86_64)
- Mac OS X 10.6, 10.7 (x86_64)
- openSUSE 12.1 (i686, x86_64)
- Solaris 5.9 (sparc)
- Solaris 5.10 & 5.11 (i386, sparc)
- SUSE Enterprise 11.2 (i686, x86_64)
- Ubuntu 10.04, 10.10, 11.04, 11.10, 12.04, 12.10 (i686, x86_64)
- Windows 2003 R2, 2008 (i686, x86_64)
- Windows 2008 R2, 2012 (x86_64)
We have sanity tested this release to the point of convergence against the following set of Chef Servers:
- OPC 1.4.6-1
- OPC 22.214.171.124-1
- Hosted Chef
- OSC 11.8
- OSC 11.6
- OSC 10.26.0
We have exercised a large set of cookbooks using a combination of test-kitchen and manual testing. Expect to see this matrix published with future releases.
Please note that this is not the totality of the test effort, only a cross-section which I thought folks might find interesting. If you have specific questions, feel free to let me know – as well as if there are specific tests which you believe will add a lot of value in what they prove and what bugs they would catch.