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:
- If your plugin fails, ohai will silently swallow the error and continue
- 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
