Hey Everyone,
Today we shipped version 4.0 of the Windows cookbook. This new release wraps up several weeks of work that was done to include many of these Windows resources in the upcoming Chef 14 release. You heard that right in Chef 14 you probably won’t need the Windows cookbook anymore! Before Chef 14 though we wanted to give everyone the benefits of all that work.
As this is a major release there are some behavior changes that everyone should be aware of. This release contains a complete rewrite to windows_feature_dism resource and includes several behavior changes to windows_feature resource. Make sure to read the complete list of changes below before deploying this to production systems. That being said this release is a major step forward for this cookbook and we think you’ll enjoy all the improvements.
DISM feature caching Ohai plugin replacement
In the 3.X cookbook we installed an Ohai plugin that cached the state of features on the node, and we reloaded that plugin anytime we installed/removed a feature from the system. This greatly sped up Chef runs where no features were actually installed/removed (2nd run and later). Without the caching each resource would take about 1 second longer while it queried current feature state. Using Ohai to cache this data was problematic though due to incompatibilities with Chef Solo, the reliance on the ohai cookbook, and the addition of extra node data which had to be stored on the Chef Server.
In the 4.0 release instead of caching data via an Ohai plugin we just write directly to the node within the resource. This avoids the need to load in the ohai plugin and the various issues that come with that. In the end it’s basically the exact same thing, but less impacting on end users and faster when the data needs to be updated.
Fail when feature is missing in windows_feature_dism
The windows_feature_dism resource had a rather un-Chef behavior in which it just warned you if a feature wasn’t available on your platform and then continued on silently. This isn’t how we handle missing packages in any of our package resource and because of that it’s not going to be what anyone expects out of the box. If someone really wants SNMP installed and we can’t install it we should fail instead of continuing on as if we did install it. So we’ll now do the following things:
- When installing a feature that doesn’t exist: fail
- When removing a feature that doesn’t exist: continue since it is technically removed
- When deleting a feature that doesn’t exist: continue since it is technically deleted
For some users, particularly those writing community cookbooks, this is going to be a breaking change. I’d highly recommend putting logic within your cookbooks to only install features on supported releases of Windows. If you’d just like it to continue even with a failure you can also use ignore_failure true on your resource although this produces a lot of failure messaging in logs.
Properly support features as an array in windows_feature_dism
We claimed to support installing features as an array in the windows_feature_dism resource previously, but it didn’t actually work. The actual result was a warning that the array of features wasn’t available on your platform since we compared the array to available features as if it was a string. We now properly support installation as a array and we do validation on each feature in the array to make sure the features are available on your Windows release. If you install more than 1 windows feature, converting it to an array will significantly speed up your Chef runs as the caching logic only needs to be performed once.
Install as the default action in windows_feature_powershell
Due to some previous refactoring the :install action was not the default action for windows_feature_powershell. For all other package resources in Chef install is the default so this would likely lead to some unexpected behavior in cookbooks. This is technically a breaking change, but I suspect everyone assumed :install was always the default.
servermanagercmd.exe Support Removal
This cookbook previously supported servermanagercmd.exe, which was necessary for feature installation on Windows 2003 / 2008 (not R2) systems. Windows 2003 went full EOL in 2015 and 2008 went into extended support in 2015 as well. Neither releases are supported platforms for Chef or this cookbook so we’ve chosen to simplify the code and remove support entirely. This removes a good chunk of the complexity in the cookbook and logic that had to run for all users.
Remove the undocumented node[‘windows’][‘rubyzipversion’] attribute
This attribute was a workaround for a bug in the rubyzip gem YEARS ago that’s just not necessary anymore. We also never documented this attribute and a resource shouldn’t change behavior based on attributes.
Other Changes
In the last 3 months we’ve shipped about half dozen releases of the Windows cookbook. These added support for Windows 10/2016, added detection of Core editions of windows, significantly cleaned up the codebase, and fixed dozens of bugs. See the changelog for a complete list of what’s new https://github.com/chef-cookbooks/windows/blob/master/CHANGELOG.md
What about Chef 14?
I did mention that this work was done so we could ship Windows resources in Chef 14. That gives Chef complete Windows support out of the box without the need for the Windows cookbook. Here’s the Windows resources you’ll see with Chef 14.0 this April:
- hostname
- windows_auto_run
- windows_font
- windows_printer
- windows_printer_port
- windows_shortcut
- windows_feature (windows_feature_powershell / windows_feature_dism)
-Tim