New Versioning
You may notice the slight but meaningful change in the version. We had always intended to follow the spirit of the Semantic Versioning Specification, but determining what version “1.0” would be kept being put off for the future. With the increase in regular releases, we want to be able to provide separate minor and patch releases, which we have been bundling together in the past.
This release of Ohai and future releases of both Chef and Ohai will be versioned X.Y.Z, where X is a major version with backwards incompatible changes to the API or other significant changes to the stack, Y is a minor version change with new features that are backwards compatible and Z is a patch release with only fixes to regressions and other bugs. The ‘master’ branch will represent the latest major version and we will be creating ‘stable-X’ branches to track the previous major version as needed. We will keep updating the Release Process page on the wiki as this evolves.
Patch releases are intended to be rapid releases with fixes for bugs or regressions and won’t always get blog posts so make sure you’re signed up for the Chef mailing list or the low traffic Opscode Announce mailing list to get notified of releases.
If you’re always installing the latest version of a release, it is important that you take the necessary actions to ensure you don’t pick up unwanted minor releases. The Omnibus and Rubygems knife bootstrap templates will install the same version of Chef on the target system that you are using on your workstation for you. The apt based bootstrap template installs the latest version on the apt repository, because reprepro only supports a single version of a package in the index. You can create your own local apt repository for testing using the reprepro cookbook.
Hinting System and The Clouds
Most of the cloud providers do not provide a reliable way to determine that your instance is running on their service. In the past we’ve relied on pieces of network information that were not definitive and those are failing us or no longer present. This release of Ohai includes a new hinting system that allows a plugin to receive a hint by the existence of a file. By default this is the directory /etc/chef/ohai/hints/. On this release if you create a file named rackspace.json, euclyptus.json or ec2.json in this directory, then Ohai will assume it is in one of those environments. We plan to modify our cloud plugins for knife to create these files next, but you can use this feature now by creating these files yourself through whatever means you prefer. These files are in the JSON format to allow passing additional information about the environment at bootstrap time, such as region or datacenter.
Other fixes
This release fixes a significant regression on Windows that was preventing the collection of network data and adds collection of uptime under Windows. It also includes a work-around to a significant Ruby bug in the garbage collector while running external commands.
Contributors
Laurent Désarmes and Eric Hankins both really came through this release, with a stellar handling of many issues related to network attributes and the hint system for the cloud attributes respectively. Both of these guys are past MVP recipients and we’re thrilled to have them still being an essential part of our community. Another MVP award to both of you!
- Laurent Désarmes added collection of ipv6 data to the iproute2 plugin, fixed detection of tun interfaces, and fixed network attribute collection with OpenVZ.
- Eric Hankins added a hint system, primarily for cloud detection.
- Hippie Hacker helped get correct ipv6 data on windows.
- Dan Crosta fixed NetBSD detection.
- Trevor Orsztynowicz added SmartOS detection.
- Zach Dunn added OmniOS detection.
- Lee Huffman updated OpenVZ support.
- Martin Vidner fixed SuSE detection.
- Chris Gaffney added a platform_family for OS X and OS X Server.
- Alan Harper added spec tests for the network plugin on OS X.
Release Notes
The Debian package has been updated. We will be releasing new Omnibus packages based on our Ruby based system for testing tomorrow, which will include this Ohai release.
Bug
- [OHAI-267] – identifying rackspace's managed cloud instances
- [OHAI-344] – Ohai does not detect server to be a Rackspace cloud server when using RackConnect
- [OHAI-305] – fe:ff:ff… arp entry not a reliable way of detecting ec2
- [OHAI-310] – EC2 Plugin does not reliably detect VPC servers
- [OHAI-322] – ohai ipaddress shows ipv6 address as inet instead of inet6, which also makes 'ohai ipaddress' sometimes default to the ipv6 address
- [OHAI-330] – Ohai crashes on Solaris 11, Ubuntu 12.04 in mixins/command.rb: popen4
- [OHAI-336] – Running ohai (and chef-client) on OSX without Java prompts user
- [OHAI-337] – SmartOS should be identified as "SmartOS" platform rather than Solaris Nevada
- [OHAI-343] – Incorrect network attributes with Ohai 0.6.12 on OpenVZ/venet
- [OHAI-345] – Missing platform_family support for OS X and OS X Server
- [OHAI-348] – openSUSE, SLE report platform "suse linux" instead of "suse"
- [OHAI-349] – "TypeError: can't convert nil into String" when using Joyent SmartOS and OHAI 0.6.12
- [OHAI-351] – network information is blank on Windows
- [OHAI-353] – node['ec2'] nil for demonized chef-client runs with Ohai 0.6.12
- [OHAI-358] – More flexible php language detection (:builddate currently broken)
- [OHAI-361] – SmartOS – remove platform_version set in platform switch
- [OHAI-362] – TUN Adapter breaks Ohai Network
- [OHAI-369] – platform for 'mint' should be 'linuxmint'
- [OHAI-371] – Ohai fails to detect NetBSD operating system type
- [OHAI-378] – Ubuntu incorrectly identified as Debian
Improvement
- [OHAI-347] – Make primary IPv6 address easier to access
- [OHAI-354] – Add recognition of Omni-Os in platform solairs
- [OHAI-370] – linux/network add ipv6 support when using iproute2
