# Ohai plugin development gotchas?

**URL:** <https://discourse.chef.io/t/ohai-plugin-development-gotchas/1853>\
**Category:** Chef Infra (archive)\
**Created:** [May 23, 2011, 2:37am UTC](https://discourse.chef.io/t/ohai-plugin-development-gotchas/1853 "2011-05-23T02:37:25Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Sascha\_Bates](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/sascha_bates/32/504_2.png) [@Sascha\_Bates](https://discourse.chef.io/u/Sascha_Bates)\
**Post date:** [May 23, 2011, 2:37am UTC](https://discourse.chef.io/t/ohai-plugin-development-gotchas/1853/1 "2011-05-23T02:37:25Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![kallistec](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kallistec/32/23_2.png) [@kallistec](https://discourse.chef.io/u/kallistec)\
**Post date:** [May 26, 2011, 4:18pm UTC](https://discourse.chef.io/t/ohai-plugin-development-gotchas/1853/2 "2011-05-26T16:18:03Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Sascha\_Bates](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/sascha_bates/32/504_2.png) [@Sascha\_Bates](https://discourse.chef.io/u/Sascha_Bates)\
**Post date:** [May 26, 2011, 4:29pm UTC](https://discourse.chef.io/t/ohai-plugin-development-gotchas/1853/3 "2011-05-26T16:29:46Z")

</div>

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](mailto: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

---

<div class="post-metadata">

**Author:** ![Jeffrey\_Hulten1](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jeffrey_hulten1/32/585_2.png) [@Jeffrey\_Hulten1](https://discourse.chef.io/u/Jeffrey_Hulten1)\
**Post date:** [May 26, 2011, 6:54pm UTC](https://discourse.chef.io/t/ohai-plugin-development-gotchas/1853/4 "2011-05-26T18:54:07Z")

</div>

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](mailto: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](mailto: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](mailto:jeffh@automatedlabs.com) 206-853-5216

---

<div class="post-metadata">

**Author:** ![Jesse\_Nelson](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/jesse_nelson/32/262_2.png) [@Jesse\_Nelson](https://discourse.chef.io/u/Jesse_Nelson)\
**Post date:** [May 26, 2011, 10:47pm UTC](https://discourse.chef.io/t/ohai-plugin-development-gotchas/1853/5 "2011-05-26T22:47:53Z")

</div>

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](mailto: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

---

<div class="post-metadata">

**Author:** ![Sascha\_Bates](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/sascha_bates/32/504_2.png) [@Sascha\_Bates](https://discourse.chef.io/u/Sascha_Bates)\
**Post date:** [May 27, 2011, 1:21am UTC](https://discourse.chef.io/t/ohai-plugin-development-gotchas/1853/6 "2011-05-27T01:21:42Z")

</div>

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 [spheromak@gmail.com](mailto: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](mailto: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