Ohai should have its own proper and dedicated configuration file

[Annih]

tl;dr: Ohai should have a separate config file e.g. /etc/ohai/config.rb & C:\ProgramData\ohai\config.rb

Current Ohai config file

Currently when I run ohai it tries to load a configuration from

theorical	linux	windows
/config.rb	/config.rb	c:\config.rb
~/.chef/config.rb	/root/.chef/config.rb	c:\Windows\system32\config\systemprofile\.chef\config.rb

Having configuration in / or c:\ is not recommended, especially when the name of the file is as generic as config.rb

Using Chef's config file

Most of the time, ohai is run via chef, so it takes its configuration via the chef's config file, but doing ohai -c my_chef_config.rb will trigger exception when the ::Chef namespace is present in my config.

Current configuration mess

Then another question arises: how do I change my ohai configuration? People would say chef-client cookbook because it's the way to change the chef's client's config; but no... I want to configure Ohai not chef client!

Another disturbing point is when I want to add a custom plugin I use ohai cookbook, but the config of the plugin path is in chef-client but there is no link between them.... outchy
When the cookbook ohai 4.0 has been released it broke the compatibility, no cookbooks were able to define new plugin, and the default directory where plugin are setup changed...
More recently chef-client cookbook changed the default configured value for the plugin_path to nil breaking again the plugins system and hardening debug.

Suggestion and benefits

As a solution to what I feel as a mess I suggest that Ohai should have a dedicated and proper config file.

linux	windows
/etc/ohai/config.rb	C:\ProgramData\ohai\config.rb

This way ohai configuration would be clearer:

• one knows that it's handled by a single file, easily configurable via chef.
• chef configuration would be handled by the chef-client cookbook *ohaiconfigwould be handled handled by ohai cookbook.

@tas50, @thommay and other Chef/Ohai maintainers what do you think?

Cc. @aboten

[tas50]

Thanks for submitting this issue. After review by the team, we've decided that this isn't something that we're going to work on ourselves. We receive dozens of new issues a month, which is more than our team can possibly work on. This means we must prioritize work and be honest about what we're able to get done as a team.  That doesn't mean that we think this is a bad idea or isn't a necessary change. It's just not something we'll likely get to given competing priorities. I've applied our Design Proposal: Accepted. PRs Welcome label to this issue and closed it out. If you or someone else would like to work on this issue we're open to pull requests. If you'd like to chat further about what that design might look reach out to us in our #chef-infra-dev slack channel.