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

[Jeffrey Hulten < >]

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

 
 206-853-5216