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

[Blake Irvin < >]

Comments inline:

On Tue, Oct 1, 2013 at 11:26 AM, Ranjib Dey < " target="_blank"> > wrote:

ohai already provides several ways to detect this. "os", "platform*", "kernel", "lsb" are few places where these information is available...Ohai is responsible for giving the system information, and its doing so correctly.

 

In the case of SmartOS at least (which is closer to BSD/Debian in userland than it is to Solaris) getting 'system information' as it relates to the kernel isn't very useful to Chef - (almos) everything that we care about is in the zone/container.  So we are getting to a place where community cookbooks that make a lot of assumptions based on 'platform' can't be easily extended to support our environment.  I'm not saying that the value ohai gives for 'platform' is wrong, just that it's incomplete for anyone doing container-style virt.

I would rather prefer to see core ohai and chef shrink in size,

Yes :)  A basic converge (even where changes aren't made) is currently slower than provisioning a host for us (granted, provisioning a zone is a lot faster than provisioning a Xen-style vm).

... ohai plugins are best for such staff.

 I haven't looked at ohai plugin code yet, but that seems like a convention to strongly consider.

 

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