Add auto detection of cloud nodes and gather facts on them using their respective metadata API

[minsis]

Proposal: Cloud fact gathering modules

Author: Dennis Whitney <@minsis> IRC: none

Date: 2024-04-25

• Status: New
• Proposal type: core
• Targeted release:
• Associated PR: I have code for Azure but not other cloud providers, no PR for it tho.
• Estimated time to implement:

Motivation

We're moving away from other automation tools like Chef which has features in ohai to detect if the node is running in a cloud environment. We utilize these types of features to determine what gets configured and what doesn't. We also use the same data to configure certain aspects of the node i.e. if server x is in region 1 then do this. This includes executing the node's respective metadata endpoint to get data on the node itself from a cloud standpoint.

So the proposal is to add this to the core fact gathering stage much like the other modules that get executed during that time.

Problems

What problems exist that this proposal will solve?
The main problem this will resolve is the need for trying to make 3rd party executions of fact gathering to determine if the node is in a cloud environment or not.

Solution proposal

Add additional fact gathering modules to include these things. I've already written an Azure one as a 3rd party plugin in my collection I'm happy to share. Other cloud services would need to be figured out. Progress has some good examples with ohai in how to detect if a node is in a cloud environment.

Dependencies (optional)

Testing (optional)

Documentation (optional)

Anything else?

[minsis]

This is my code for Azure detection but its made as a module for a collection. I'd be happy to rewrite it for Ansible core and create a PR for it.

https://gist.github.com/minsis/5a2c2ae767925af4414d578cadd67822

[bcoca]

normally it is simpler to have the cloud inventory plugin add that information as a group or host variable, you could even infer it from the inventory_file variable already associated with each host.

[minsis]

We use ServcieNow for our dynamic inventory sync into AAP/AWX which also does not have that info without a bunch of extra calls. Each server runs a callback to AAP/AWX in order to maintain its own state, so our use case mimics a bit like Chef does in this case.

[bcoca]

another option is adding a vars plugin that does the api query when needed

[minsis]

The API query is done on the remote host. i.e. http://169.254.169.254/metadata/instance. Hence why I think it's a nicer fit during fact gathering stage along with all the other facts that are being gathered. Reference: https://learn.microsoft.com/en-us/azure/virtual-machines/instance-metadata-service?tabs=windows

And to iterate I dont know when any of it needs to be executed. Our inventory is gathered dynamically from a CMDB which is just simply saying "here's a list of Linux and/or Windows server hostnames". This is probably why chef has added these features. In fact, they went one step further and even added a built-in check so you can ask if the node is cloud based, Azure, GCE, or AWS, among a few others, specifically. Reference: https://docs.chef.io/infra_language/checking_clouds/