Watch: Build a Custom Ohai Plugin

On February 1st, I presented a live webinar titled “Build a Custom Ohai Plugin”. Watch the recording below to hear me explain the purpose of Ohai, the structure and language of its plugins, and how you can write a unit test and integration test for your plugin.

In the presentation, I start by demonstrating how Ohai can be used on the command-line and within the chef-client run. I then talk a little about understanding and opening Ruby gems. This is particularly important because the Ohai gem comes with many great plugin examples. Then, we build and test a plugin locally with ChefSpec and complete the adventure with a recipe and an InSpec test.

During the presentation and afterwards, in the community slack channel #webinar-topics, I was asked a few questions that I have included here in this post.

Q&A

Can you recommend further resources about building custom Ohai plugins specifically for Windows platforms?

The Ohai gem contains a collection of core plugins that span many platforms. You can find all of these plugins within the ‘ohai/lib/ohai/plugins’ directory.

There is a directory for quite a few platforms. Within the windows directory you will find examples on how memory, CPU, and other core attributes are collected.

Those plugins will collect data for only Windows. The package plugin is an example of a plugin that collects data differently based on the platform. It has an implementation for Linux and Windows.

How often does ohai update Chef Server of node attributes? For example, if more memory is dynamically allocated to node, how soon will memory attributes be updated on chef-server?

Ohai, the application, will never update the Chef Server. It only collects and reports that data. The application that updates node objects with updated Ohai data would be chef-client.

There is a slide in the presentation that shows the lifecycle of when the data is collected for a chef-client run. The node information is collected at the start of a chef-client run and will only send the final state of the node object to the Chef Server if the node completes a chef-client successfully.

My suggestion would be to run chef-client as often as you are able to on your owns to ensure they are up-to-date.

We currently use a recipe to take some data from a registry key and set it as a group of node attributes. There’s talk of changing this to be an Ohai plugin instead, but what would be the purpose of doing so? It already works as it is.

Finding data about the node and setting it in a recipe accomplishes the same work. At the end of the day, the node is reporting back information about itself. Let’s talk about two situations, that I see, that may lead you to choose an Ohai plugin over node attributes set in a recipe.

First, node attributes set through a recipe will only be set when that recipe is evaluated. This could create a problem if recipes, that depend on these attributes, are evaluated before the recipe that you defined.

Second, node attributes set through a recipe can be overridden at various locations. It is not usually the case but your data could become overridden incorrectly and causing your system to report incorrectly or behave incorrectly.