make hint system more user-friendly about ohai HOT 9 CLOSED

One of the forward looking things that align with this is the idea of having :optional plugins which can be enabled via Ohai::Config. However it is arguable easier to drop a hints file via Chef rather than updating config file via Chef.

from ohai.

That is true only if you are already running Chef on your box - doesn't help you in the bootstrapping use case.

Also, if there's pain in updating Chef's config file with Chef then that's arguably something we should look into fixing... for obvious reasons 😁

from ohai.

I think the way to update Chef's config file via Chef is to use the chef-client cookbook. If you're using that 👍 but otherwise you'll be :sadpanda:

I'm not clear on how the bootstrapping use case will work? Like below:

knife bootstrap my_node --ohai-hints ec2,azure

from ohai.

@sersut Yeah, that would work, 'cause is there any situation in which a hint isn't a boolean? We could then make the bootstrap template write out a line into the client.rb with the hints turned on, e.g.

Ohai[:hints] = ['ec2', 'whatevs']

from ohai.

Makes sense... Probably config should co-exist with the hint files in order not to break backwards compat.

from ohai.

@juliandunn There are some plugins which rely on hints data to populate the plugin data. For example, the azure plugin only reads azure.json.

On the surface, it seems hints serve a single function: to provide Ohai with information that it can't provide itself. But that largely breaks into two categories: a boolean stating presence of data Ohai can then go look for (e.g., ec2 plugin), or directly providing Ohai with data it can't find, or isn't finding, on its own (e.g., the azure plugin).

It's confusing to know when it's a boolean case and when it's a "provide the JSON" case. I think we need to distinguish between the two more concretely.

from ohai.

👍 to @mcquin on the purpose of hints being "to provide Ohai with information that it can't provide itself."

I've seen people want to use Ohai hints for purposes that we already have other mechanisms for like node attributes and tags. Hints were meant to be a last case scenario for detection of system information, not another path for user data. I wouldn't want to break the ability to pass in JSON data via hints to allow someone to easily trigger a hint from the command line. We knows that we want to be able to push in some cloud data now and then. See OHAI-267 for the original discussion.

Hints shouldn't be a configuration flag alone, because then anything else that wants to provide a hint to Ohai would need to edit the configuration file. The hints directory acts like a .d directory, allowing knife and other tools to drop data in without having to parse the configuration file.

from ohai.

Previously we needed hints for just about every cloud plugin as we lacked ways to properly detect the providers. For the last 8+ months we've had solid auto detection on all clouds except Azure which lacks a metadata endpoint. Rackspace, GCE, EC2, Openstack all auto detect and grab metadata. Ideally people just stop using the hints. If Azure gets a metadata endpoint we can move to a world where the hints are an optional fallback when things don't work as they should.

from ohai.

I'm going to close this out at this point. We've eliminated the main reason for using the hints and I don't see the return being worth the effort of refactoring at this point.

from ohai.