Allowing plugins to be marked as required in Ohai


#1

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?


Bryan McLellan | opscode | senior systems administrator
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org

[1] http://tickets.opscode.com/browse/OHAI-87


#2

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
© 206.607.7108 | (t) @btmspox | (b) http://blog.loftninjas.org

[1] http://tickets.opscode.com/browse/OHAI-87