-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add auto detection of cloud nodes and gather facts on them using their respective metadata API #211
Comments
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 |
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 |
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. |
another option is adding a vars plugin that does the api query when needed |
The API query is done on the remote host. i.e. 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/ |
Proposal: Cloud fact gathering modules
Author: Dennis Whitney <@minsis> IRC: none
Date: 2024-04-25
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?
The text was updated successfully, but these errors were encountered: