make hint system more user-friendly

[juliandunn]

The mechanism by which users pass in hints to Ohai is not the most user-friendly (JSON blobs that are either empty or with mysterious contents). Could we consider refactoring it to just be a configuration flag?

[sersut]

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.

[juliandunn]

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 😁

[sersut]

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

[juliandunn]

@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']

[sersut]

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

[mcquin]

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

[btm]

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

[tas50]

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.

[tas50]

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.