Ohai plugin development gotchas?


#1

I’ve written a chunk of ruby that parses a host name and returns several key
pieces of information that we want to use as attributes. Some are new
attributes and some we have been using by setting roles with one attribute
on the node. This is mostly environment-related stuff, one way or another;
data center location, prod/dev/qa environment, zoning (internet facing,
etc), server type (web/app/image/db), and other things. I’d like to get
away from using roles to manage this as we have hundreds of
(logically-named) servers that Chef will ultimately mange and run list
management is still very manual.

I was thinking to make it an ohai plugin since that sets node attributes
very early on and can’t be overridden. I was wondering if anyone else has
been doing much with ohai plugins and if they’ve run into any issues or
problems that I should be aware of before I go down this path? We’re
currently running .09.12 but trying to find the time to move to .10.

Thanks,
Sascha


#2

On Sunday, May 22, 2011 at 7:37 PM, Sascha Bates wrote:

I’ve written a chunk of ruby that parses a host name and returns several key pieces of information that we want to use as attributes. Some are new attributes and some we have been using by setting roles with one attribute on the node. This is mostly environment-related stuff, one way or another; data center location, prod/dev/qa environment, zoning (internet facing, etc), server type (web/app/image/db), and other things. I’d like to get away from using roles to manage this as we have hundreds of (logically-named) servers that Chef will ultimately mange and run list management is still very manual.

I was thinking to make it an ohai plugin since that sets node attributes very early on and can’t be overridden. I was wondering if anyone else has been doing much with ohai plugins and if they’ve run into any issues or problems that I should be aware of before I go down this path? We’re currently running .09.12 but trying to find the time to move to .10.

Thanks,
Sascha
If you’re looking to do assignment of run lists based on hostname, that won’t work, since the run list isn’t an attribute of the node (in the chef sense of the word “attribute”).

That said, ohai plugins are pretty simple to develop, it should be easy to figure it out from the existing plugins.

As for “gotchas” the only things I can think of are:

  1. If your plugin fails, ohai will silently swallow the error and continue
  2. If you’re on CentOS 5, running IO.read on certain proc “files” in ohai will cause shef to hang on start due to an unpatched kernel bug.

There has been some discussion of modifying ohai’s architecture to make some plugins “mandatory” such that a failure would fail ohai, but no solid plan to implement it yet.


Dan DeLeo


#3

Thanks. I’m working on a client that has an entirely internal
infrastructure with no overall system that we can get information about
hosts from. However, we can know a lot about a host based on its name: data
center, application, type (app/web/db/etc), env (dev, qa, etc). I basically
wrote a ruby function that parses the name and returns a hash of server
details that can be used by recipes for logic on what to based on data
center, env, etc.

Once I had the function working, I transformed it to an ohai custom plugin
that returns node level attributes of env, location and zone, along with an
additional hash containing interesting information that is less critical. I
did notice that Ohai threw a pretty critical error that didn’t show up
unless I ran debug:

[Tue, 24 May 2011 10:22:10 -0500] DEBUG: Plugin parse_host_plugin threw
exception

I didn’t keep any more info about the problem though so I can’t remember
what it was about. Anyway, I implemented it and it’s working pretty well.
It’s too bad it’s totally client specific.

It’s the first thing I’ve written outside of recipes, so I’m pretty excited
about the whole thing and the ease of making the plugin has given me several
ideas for other things I really want to do.

Sascha

On Thu, May 26, 2011 at 11:18 AM, Daniel DeLeo dan@kallistec.com wrote:

On Sunday, May 22, 2011 at 7:37 PM, Sascha Bates wrote:

I’ve written a chunk of ruby that parses a host name and returns several
key pieces of information that we want to use as attributes. Some are new
attributes and some we have been using by setting roles with one attribute
on the node. This is mostly environment-related stuff, one way or another;
data center location, prod/dev/qa environment, zoning (internet facing,
etc), server type (web/app/image/db), and other things. I’d like to get away
from using roles to manage this as we have hundreds of (logically-named)
servers that Chef will ultimately mange and run list management is still
very manual.

I was thinking to make it an ohai plugin since that sets node attributes
very early on and can’t be overridden. I was wondering if anyone else has
been doing much with ohai plugins and if they’ve run into any issues or
problems that I should be aware of before I go down this path? We’re
currently running .09.12 but trying to find the time to move to .10.

Thanks,
Sascha
If you’re looking to do assignment of run lists based on hostname, that
won’t work, since the run list isn’t an attribute of the node (in the chef
sense of the word “attribute”).

That said, ohai plugins are pretty simple to develop, it should be easy to
figure it out from the existing plugins.

As for “gotchas” the only things I can think of are:

  1. If your plugin fails, ohai will silently swallow the error and continue
  2. If you’re on CentOS 5, running IO.read on certain proc “files” in ohai
    will cause shef to hang on start due to an unpatched kernel bug.

There has been some discussion of modifying ohai’s architecture to make
some plugins “mandatory” such that a failure would fail ohai, but no solid
plan to implement it yet.


Dan DeLeo


#4

If nothing else, a specific exception that can be passed up (doesn’t
get swallowed) to the chef-client or causes the ohai cli to exit would
be nice.

On Thu, May 26, 2011 at 9:29 AM, Sascha Bates sascha.bates@gmail.com wrote:

Thanks. I’m working on a client that has an entirely internal
infrastructure with no overall system that we can get information about
hosts from. However, we can know a lot about a host based on its name: data
center, application, type (app/web/db/etc), env (dev, qa, etc). I basically
wrote a ruby function that parses the name and returns a hash of server
details that can be used by recipes for logic on what to based on data
center, env, etc.

Once I had the function working, I transformed it to an ohai custom plugin
that returns node level attributes of env, location and zone, along with an
additional hash containing interesting information that is less critical. I
did notice that Ohai threw a pretty critical error that didn’t show up
unless I ran debug:

[Tue, 24 May 2011 10:22:10 -0500] DEBUG: Plugin parse_host_plugin threw
exception

I didn’t keep any more info about the problem though so I can’t remember
what it was about. Anyway, I implemented it and it’s working pretty well.
It’s too bad it’s totally client specific.

It’s the first thing I’ve written outside of recipes, so I’m pretty excited
about the whole thing and the ease of making the plugin has given me several
ideas for other things I really want to do.

Sascha

On Thu, May 26, 2011 at 11:18 AM, Daniel DeLeo dan@kallistec.com wrote:

On Sunday, May 22, 2011 at 7:37 PM, Sascha Bates wrote:

I’ve written a chunk of ruby that parses a host name and returns several
key pieces of information that we want to use as attributes. Some are new
attributes and some we have been using by setting roles with one attribute
on the node. This is mostly environment-related stuff, one way or another;
data center location, prod/dev/qa environment, zoning (internet facing,
etc), server type (web/app/image/db), and other things. I’d like to get away
from using roles to manage this as we have hundreds of (logically-named)
servers that Chef will ultimately mange and run list management is still
very manual.

I was thinking to make it an ohai plugin since that sets node attributes
very early on and can’t be overridden. I was wondering if anyone else has
been doing much with ohai plugins and if they’ve run into any issues or
problems that I should be aware of before I go down this path? We’re
currently running .09.12 but trying to find the time to move to .10.

Thanks,
Sascha
If you’re looking to do assignment of run lists based on hostname, that
won’t work, since the run list isn’t an attribute of the node (in the chef
sense of the word “attribute”).

That said, ohai plugins are pretty simple to develop, it should be easy to
figure it out from the existing plugins.

As for “gotchas” the only things I can think of are:

  1. If your plugin fails, ohai will silently swallow the error and continue
  2. If you’re on CentOS 5, running IO.read on certain proc “files” in ohai
    will cause shef to hang on start due to an unpatched kernel bug.

There has been some discussion of modifying ohai’s architecture to make
some plugins “mandatory” such that a failure would fail ohai, but no solid
plan to implement it yet.


Dan DeLeo


Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
jeffh@automatedlabs.com 206-853-5216


#5

you can also implement this in a library inside a cookbook that has an attrib that calls your helper method to resolve info about your environment. Then recipes can call this or you can set default attribs etc. As long as your helper cookbook is early in the run_list all is well.

On May 26, 2011, at 9:29 AM, Sascha Bates wrote:

Thanks. I’m working on a client that has an entirely internal infrastructure with no overall system that we can get information about hosts from. However, we can know a lot about a host based on its name: data center, application, type (app/web/db/etc), env (dev, qa, etc). I basically wrote a ruby function that parses the name and returns a hash of server details that can be used by recipes for logic on what to based on data center, env, etc.

Once I had the function working, I transformed it to an ohai custom plugin that returns node level attributes of env, location and zone, along with an additional hash containing interesting information that is less critical. I did notice that Ohai threw a pretty critical error that didn’t show up unless I ran debug:

[Tue, 24 May 2011 10:22:10 -0500] DEBUG: Plugin parse_host_plugin threw exception

I didn’t keep any more info about the problem though so I can’t remember what it was about. Anyway, I implemented it and it’s working pretty well. It’s too bad it’s totally client specific.

It’s the first thing I’ve written outside of recipes, so I’m pretty excited about the whole thing and the ease of making the plugin has given me several ideas for other things I really want to do.

Sascha

On Thu, May 26, 2011 at 11:18 AM, Daniel DeLeo dan@kallistec.com wrote:

On Sunday, May 22, 2011 at 7:37 PM, Sascha Bates wrote:

I’ve written a chunk of ruby that parses a host name and returns several key pieces of information that we want to use as attributes. Some are new attributes and some we have been using by setting roles with one attribute on the node. This is mostly environment-related stuff, one way or another; data center location, prod/dev/qa environment, zoning (internet facing, etc), server type (web/app/image/db), and other things. I’d like to get away from using roles to manage this as we have hundreds of (logically-named) servers that Chef will ultimately mange and run list management is still very manual.

I was thinking to make it an ohai plugin since that sets node attributes very early on and can’t be overridden. I was wondering if anyone else has been doing much with ohai plugins and if they’ve run into any issues or problems that I should be aware of before I go down this path? We’re currently running .09.12 but trying to find the time to move to .10.

Thanks,
Sascha
If you’re looking to do assignment of run lists based on hostname, that won’t work, since the run list isn’t an attribute of the node (in the chef sense of the word “attribute”).

That said, ohai plugins are pretty simple to develop, it should be easy to figure it out from the existing plugins.

As for “gotchas” the only things I can think of are:

  1. If your plugin fails, ohai will silently swallow the error and continue
  2. If you’re on CentOS 5, running IO.read on certain proc “files” in ohai will cause shef to hang on start due to an unpatched kernel bug.

There has been some discussion of modifying ohai’s architecture to make some plugins “mandatory” such that a failure would fail ohai, but no solid plan to implement it yet.


Dan DeLeo


#6

That’s actually why I moved to ohai, because one of my attributes was not
getting set early enough. I needed it for logic inside an attribute file
and, while I eventually worked around it with other logic, I found the
solution unsatisfying :slight_smile:

On Thu, May 26, 2011 at 5:47 PM, Jesse Nelson spheromak@gmail.com wrote:

you can also implement this in a library inside a cookbook that has an
attrib that calls your helper method to resolve info about your environment.
Then recipes can call this or you can set default attribs etc. As long as
your helper cookbook is early in the run_list all is well.

On May 26, 2011, at 9:29 AM, Sascha Bates wrote:

Thanks. I’m working on a client that has an entirely internal
infrastructure with no overall system that we can get information about
hosts from. However, we can know a lot about a host based on its name: data
center, application, type (app/web/db/etc), env (dev, qa, etc). I basically
wrote a ruby function that parses the name and returns a hash of server
details that can be used by recipes for logic on what to based on data
center, env, etc.

Once I had the function working, I transformed it to an ohai custom plugin
that returns node level attributes of env, location and zone, along with an
additional hash containing interesting information that is less critical. I
did notice that Ohai threw a pretty critical error that didn’t show up
unless I ran debug:

[Tue, 24 May 2011 10:22:10 -0500] DEBUG: Plugin parse_host_plugin threw
exception

I didn’t keep any more info about the problem though so I can’t remember
what it was about. Anyway, I implemented it and it’s working pretty well.
It’s too bad it’s totally client specific.

It’s the first thing I’ve written outside of recipes, so I’m pretty excited
about the whole thing and the ease of making the plugin has given me several
ideas for other things I really want to do.

Sascha

On Thu, May 26, 2011 at 11:18 AM, Daniel DeLeo dan@kallistec.com wrote:

On Sunday, May 22, 2011 at 7:37 PM, Sascha Bates wrote:

I’ve written a chunk of ruby that parses a host name and returns several
key pieces of information that we want to use as attributes. Some are new
attributes and some we have been using by setting roles with one attribute
on the node. This is mostly environment-related stuff, one way or another;
data center location, prod/dev/qa environment, zoning (internet facing,
etc), server type (web/app/image/db), and other things. I’d like to get away
from using roles to manage this as we have hundreds of (logically-named)
servers that Chef will ultimately mange and run list management is still
very manual.

I was thinking to make it an ohai plugin since that sets node attributes
very early on and can’t be overridden. I was wondering if anyone else has
been doing much with ohai plugins and if they’ve run into any issues or
problems that I should be aware of before I go down this path? We’re
currently running .09.12 but trying to find the time to move to .10.

Thanks,
Sascha
If you’re looking to do assignment of run lists based on hostname, that
won’t work, since the run list isn’t an attribute of the node (in the chef
sense of the word “attribute”).

That said, ohai plugins are pretty simple to develop, it should be easy to
figure it out from the existing plugins.

As for “gotchas” the only things I can think of are:

  1. If your plugin fails, ohai will silently swallow the error and continue
  2. If you’re on CentOS 5, running IO.read on certain proc “files” in ohai
    will cause shef to hang on start due to an unpatched kernel bug.

There has been some discussion of modifying ohai’s architecture to make
some plugins “mandatory” such that a failure would fail ohai, but no solid
plan to implement it yet.


Dan DeLeo