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

[Daniel DeLeo < >]

On Tuesday, October 1, 2013 at 12:17 PM, Blake Irvin wrote:

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.

For example, Ubuntu, CentOS, etc. are all on the Linux kernel, and could be on the same kernel version or not. Platform implies more than just the kernel. FWIW, kernel info goes under the kernel attribute. For example:

https://github.com/opscode/ohai/blob/master/lib/ohai/plugins/linux/platform.rb

https://github.com/opscode/ohai/blob/master/lib/ohai/plugins/solaris2/platform.rb

Example data:

:~$ ohai platform

[

  "ubuntu"

]

:~$ ohai kernel

{

  "name": "Linux",

  "release": "3.8.0-19-generic",

  "version": "#29-Ubuntu SMP Wed Apr 17 18:16:28 UTC 2013",

  "machine": "x86_64",

<lots of stuff about kernel modules>

The OS just needs to expose some way for us to get the info we need to detect the platform. There's a few standards for this but they're not really great in practice so I don't have a preference for how this is done (not that it would matter anyway).

 

 

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.)

This is what we have so far for solaris:

https://github.com/opscode/ohai/blob/master/lib/ohai/plugins/solaris2/virtualization.rb

 

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.

In the current implementation, we have one big hash that says which platform gets what: https://github.com/opscode/chef/blob/master/lib/chef/platform/provider_mapping.rb

 

-- 

Daniel DeLeo