[chef] Re: ohai plugin development gotchas?

[Daniel DeLeo < >]

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