Skip to content
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 examples how to make inventory caching interoperable with fact caching #1689

Open
0xFelix opened this issue Jul 12, 2024 · 4 comments
Open
Labels
new_contributor This PR is the first contribution by a new community member.

Comments

@0xFelix
Copy link

0xFelix commented Jul 12, 2024

After recent discussions I learned that if dynamic inventories cache their facts on a per host basis, then their cache can become interoperable with fact caching in Ansible.

Unfortunately this is nowhere documented and I couldn't find a single inventory that implements caching in this way. If I'm not mistaken, then all of the inventories included in the Ansible distribution only make use of source caching, to avoid load on the inventory's data source.

It would be great if more examples could be added to Developing dynamic inventory to show how caching can be made more efficient.

@ansible-documentation-bot ansible-documentation-bot bot added needs_triage Needs a first human triage before being processed. new_contributor This PR is the first contribution by a new community member. labels Jul 12, 2024
@ansible-documentation-bot
Copy link
Contributor

Thanks for your Ansible docs contribution! We talk about Ansible documentation on matrix at #docs:ansible.im and on libera IRC at #ansible-docs if you ever want to join us and chat about the docs! We meet there on Tuesdays (see the Ansible calendar) and welcome additions to our weekly agenda items - scroll down to find the upcoming agenda and add a comment to put something new on that agenda.

@samccann samccann removed the needs_triage Needs a first human triage before being processed. label Jul 16, 2024
@samccann
Copy link
Contributor

Hey @0xFelix - do you have details from your discussions that you can add here to the issue?

@0xFelix
Copy link
Author

0xFelix commented Jul 17, 2024

From discussion with @bcoca I gathered:

  • Cache plugins were designed to be by host for fact cache
  • It's a way to keep the inventory small even if it has a huge amount of variables, by using the fact cache you can make them 'on demand' for only the hosts used in play
  • If you want to use the fact cache as a way to optimize inventory size and variable loading you should use host keys and match the settings when using the fact cache
  • The current caching example mostly reflects caching 'inventory generating data' and is designed to store/retrieve a single API response
  • The docs need more examples for multiple API calls and for fact caching

@bcoca
Copy link
Member

bcoca commented Jul 17, 2024

Adding more to the pile:

  • Cache plugins were designed to be by host for fact cache, but later adapted to also support inventory plugins
  • They CAN be used as a way to keep the inventory small even if it has a huge amount of variables, by using the fact cache you can make them 'on demand' for only the hosts used in play.
  • You CAN also use vars plugins the same way, they were designed as a more direct way of doing this. The host_vars/group_vars vars loading, for example, is implemented via the host_group_vars vars plugin but there are vars plugin that query APIs, just like inventories (still working on a way to avoid overlapping/reuse credentials across them).
  • The choice of which to use requires looking at variable precedence, performance and complexity
  • We also need a step by step tutorial for plugin devs in general, with an intro on why to develop as specific plugin type and what APIs are available to each type (really all of Ansible is, but most of that is not 'public/supported' API and can change w/o notice).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new_contributor This PR is the first contribution by a new community member.
Projects
Status: 🆕 Triage
Development

No branches or pull requests

3 participants