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

[Blake Irvin < >]

Comments inline:

On Tue, Oct 1, 2013 at 11:36 AM, Daniel DeLeo < " target="_blank"> > wrote:

Sounds like you just need to make the solaris platform plugin a little smarter? If SmartOS and SNGL are functionally different, they should be reported as different platforms. It's up to Joyent to provide a sane way to detect this, and then you can patch the plugin to handle that case.

I guess I'm unsure about the semantics of the 'platform' attribute - if we expect it to tell us what kernel rev we are one, I *cannot* use it to report SNGL vs plain SmartOS, because zones of each type may be running on the same kernel rev, yet will be functionally different higher up the stack.  I've already talked to Joyent about providing means to detect container 'flavor' - that's in the works for SNGL GA release, I think.

 

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

Does ohai's virtualization detection cover these cases? If not, can it be made to do so?

That answers my question, maybe, about how to name container-specific attributes - can we adopt the conventions used for other virtualization flavors?  (Not sure quite where to do this, so pointers would be helpful - we don't mind contributing features upstream.)

 

As for non-default package managers, this is more of a Chef issue than an ohai issue, though there is some overlap. But if ohai can detect SNGL as distinct from SmartOS, then you just need to add the right entries in the platform selection code that exists now and everything should be fine.

Having the Chef pkg resource code handle this does sound like the right plan to me, though I think that this will end up being coupled to ohai correctly reporting container flavor.