[chef-dev] Re: improving ohai's awareness of OS 'flavors'

[Ranjib Dey < >]

ohai already provides several ways to detect this. "os", "platform*", "kernel", "lsb" are few places where these information is available. Ohai's notion of OS and platform is orthogonal, you can have multiple platform_family that belongs to same OS. I dont know much about solaris, but i could detect my custom kernel use node.kernel.release. In linux, generally the platform_family is sufficient to decide the provider for a resource, if thats not the case and you have to add conditional logic based on kernel versions , that should go inside the provider, not ohai (you can do the same inside a recipe as well). Ohai is responsible for giving the system information, and its doing so correctly.

I would rather prefer to see core ohai and chef shrink in size,  and instead provide a stable api for extensibility. Event dispatchers, hint system for cloud platform detection are examples on this direction. Ohai and Chef's loading time is already a pain. And with introduction of more and more platform specific code we now have several blocking yet legitimate bugs that are now part of core chef (which were not there before), and this now prevents us from using upstream Chef.

I dont know exactly what additional information you would be able to fetch from a container specific attributes, as the lxc/openvz templates already drops the /etc/plattform*-(release| version) file, which ohai internally uses to detect platform. The only thing i can think of is introspecting /proc/mount and that might give a hint that we are inside a container. And a ohai plugins are best for such staff.

best

ranjib

On Tue, Oct 1, 2013 at 10:31 AM, Blake Irvin < " target="_blank"> > wrote:

At my day job (Wanelo), we do almost all of our work in SmartOS zones.  This means that, while 'uname' and similar commands will detect the global zone properly, this isn't actually that useful for automation, as it's the local zone configuration that's more important.  (For more on zones in SmartOS, see this document).

For example, Joyent is working on a 'flavor' of SmartOS called SNGL, which is meant to encourage a platform-agnostic approach to systems choice (basically, userland in SNGL looks a lot more like Debian-flavored Linux than mainline SmartOS).  While this is useful insofar as it should allow better cross-platform behavior for community cookbooks, it's also a pain for Chef users because ohai can only identify platform by kernel-specific information, which all zones on a piece of physical hardware, SNGL or otherwise, share.

Wrestling with these problems, it occurred to us that there are broader implications to the way that ohai reports platform information.  For example:

- It's hard to tell from ohai-generated attributes if you are on a custom-built AWS AMI that might need different Chef behavior than the 'stock' OS you baselined from

- Users of other 'container' technologies (jails/lxc) will likely need to identify container 'flavor'

- Anyone who prefers a package manager that's not the default for their system will have to monkeypatch ohai or hard-code attributes

A few extensions to ohai seem possible:

- Make ohai container-aware (that is, aware if it's being run inside a container and able to report container configuration) through additional attributes

- Make ohai package manager aware (that is, don't assume package manager X just because you're on kernel Y) through additional attributes

Before doing any work on this (likely in the form of a cookbook extending the platform attribute namespace) we'd like some feedback from people here on the Right Way™ to do this.

best,

Blake