Ohai, it’s been awhile!
Since the last release was almost four months ago and we've had some new features added and some hairy bugs squashed, we thought a new version of Ohai, our system information gathering tool used with Chef, was in order.
Our community rocks for finding bugs and reporting tickets and also for fixing these issues and making improvements! Mark Imbriaco identified a bug where zombie processes were being created, and Matthew Kent fixed it. Mathieu Sauve-Frankel returned with some contributions like a Perl plugin, and a fix for the Python plugin throwing an exception.
One of Opscode's advisors, Benjamin Black, added code to handle incremental updates to data and re-running plugins (say through Nanite). He also fixed some bugs and improved the data returned for network interfaces.
Opscode added additional data about the Ruby environment – the default gem installation path and which Ruby binary is used. A new feature a long time coming is the ability to specify one or more attributes and return only those, rather than the entire JSON blob. Note this only works on toplevel attributes (hostname, platform, languages, etc), but we plan to have the ability to narrow down in a near-term release.
And now, the release notes:
- [OHAI-69] – plugins/network.rb has unused and broken code relating to attribute "default_interface"
- [OHAI-76] – darwin kernel spec fails on linux system
- [OHAI-77] – no method error from current HEAD for 'chomp!'
- [OHAI-79] – Ohai::Exception was leaking into popen4, causing us to lose the exception raised by exec (Errno::ENOENT)
- [OHAI-82] – libvirt call fails with undefine method 'openReadOnly' for Libvirt:Module (NoMethodError)
- [OHAI-86] – ohai leaves zombie processes in it's wake.
- [OHAI-91] – dmi plugin should check version of dmidecode, only load attributes available.
- [OHAI-81] – languages[:ruby] should also know about the gemdir and ruby binary
- [OHAI-83] – minor fix for libvirt not installed