[[chef-dev]] Re: [[chef-dev]] Allowing plugins to be marked as required in Ohai


Chronological Thread 
  • From: Daniel DeLeo < >
  • To: Bryan McLellan < >
  • Cc:
  • Subject: [[chef-dev]] Re: [[chef-dev]] Allowing plugins to be marked as required in Ohai
  • Date: Wed, 10 Aug 2011 09:04:21 -0700

On Thursday, August 4, 2011 at 12:17 PM, Bryan McLellan wrote:
> Currently Ohai wraps plugins in a rescue block. If they fail for any
> reason, most often because they require an optional gem that the user
> does not have installed, we still chug along. In some circumstances,
> these failures are unacceptable because Chef or a cookbook relies on
> that data. OHAI-87 [1] is one example, where the ipaddress wasn't
> being returned by Ohai. In that was, this was worked around by
> enforce_path_sanity which shipped in Chef 0.10. Ohai inherits the path
> configured by chef on fork (but not when run directly on the command
> line).
> 
> Are the circumstances and use cases where we want to specify that
> certain plugins must succeed or Ohai should fail? Should this be
> easily configurable or something hardcoded with each release? Should
> you be able to set it in a Chef recipe without changing an Ohail
> configuration file?

Here are some real-world scenarios I can name off the top of my head:

* You don't correctly set your hostname in /etc/hosts so your hostname is 
nil. Chef later fails with "attribute is not defined" attempting to create a 
node. This is hell on new chef users.
* EC2 plugin randomly errors out. Your node gets saved without the 
ec2.public_hostname attribute, and you can't access it via knife ssh.

A related issue that I've discussed with other developers is the possibility 
of making plugins opt-in instead of opt-out. This comes up on very large 
installations where the sheer volume of attributes taxes the disk I/O 
capabilities of the database. The two issues don't _have to_ be addressed 
concurrently, but one possibility is that you could opt-in to specific ohai 
plugins and none would be allowed to fail.

As for deciding which plugins are required to succeed, I would hope that a 
sane default could be enabled automatically, with overrides available for use 
cases that require it. Doing the right thing for the cloud plugins will be 
tricky, since you expect them to fail if you're not in the cloud (or in a 
known cloud), but you almost certainly don't want them to fail if you are.


-- 
Dan DeLeo 
> 
> -- 
> Bryan McLellan | opscode | senior systems administrator
> (c) 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org
> 
> [1] http://tickets.opscode.com/browse/OHAI-87





Archive powered by MHonArc 2.6.16.

§