[chef] Re: Re: Re: Re: ohai plugin development gotchas?

[Sascha Bates < >]

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 :)

On Thu, May 26, 2011 at 5:47 PM, Jesse Nelson < "> > 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 < " target="_blank"> > 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