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

Support a way for fact collectors to depend on other collectors #31006

Closed
alikins opened this issue Sep 27, 2017 · 3 comments
Closed

Support a way for fact collectors to depend on other collectors #31006

alikins opened this issue Sep 27, 2017 · 3 comments
Assignees
Labels
affects_2.5 This issue/PR affects Ansible v2.5 feature This issue/PR relates to a feature request. support:core This issue/PR relates to code supported by the Ansible Engineering Team.

Comments

@alikins
Copy link
Contributor

alikins commented Sep 27, 2017

  • Feature Idea
COMPONENT NAME

lib/ansible/module_utils/facts/

SUMMARY

Allow fact collectors to indicate if they need information from another fact collector to be gathered first.

Some fact collectors require information to be gathered by other fact collections before they run, so
we need to be able to order the collector runs. To do this, the fact collectors need a way to indicate their dependencies, and the ansible_collector used by setup.py needs to understand how to use that info.

ie, a fact collector dep solver more or less.

The most common case for this is collectors that need to know the systems platform infomation ('ansible_system', 'ansible_machine, 'ansible_distribution', etc). But for custom fact collection modules, there may be other cases (some of the openshift fact collectors depend on other openshift collectors
for example).

possible implementations
  • A traditional dep solver and topological ordering

collectors would indicate their deps so they could be resolved and topological sorted so dependent collectors always run before depending collectors.

A wip / proof of concept branch exists at devel...alikins:fact_collector_ordering_gather_spec

  • Require explicit collector odering

Since the number of collectors with dependencies is small (at least in default ansible facts) it may be simple just to specify an explicit ordering to run collectors in. Custom fact collectors would also need to be able to specify this.

possible alternatives
  • eliminate the dependencies altogether

For the default set of facts, this is probably doable. There is a small number of deps, and most are platform infomation requirements. Since there is already support for choosing the implementation of a fact collector based on system platform information, most/all of the deps could be eliminated.

But for collector ordering deps that depend on other info (like the openshift fact modules), this may not be doable.

EXPECTED RESULTS
ACTUAL RESULTS

@alikins alikins added this to the 2.5.0 milestone Sep 27, 2017
@ansibot ansibot added affects_2.5 This issue/PR affects Ansible v2.5 support:core This issue/PR relates to code supported by the Ansible Engineering Team. labels Sep 27, 2017
@alikins alikins self-assigned this Oct 20, 2017
@ansibot
Copy link
Contributor

ansibot commented Nov 21, 2017

Files identified in the description:

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

@ansibot ansibot added feature This issue/PR relates to a feature request. and removed feature_idea labels Mar 2, 2018
@bcoca bcoca removed this from the 2.5.0 milestone Aug 28, 2018
@ansibot ansibot added support:community This issue/PR relates to code supported by the Ansible community. and removed support:core This issue/PR relates to code supported by the Ansible Engineering Team. labels Sep 21, 2018
@ansibot
Copy link
Contributor

ansibot commented Apr 29, 2020

Files identified in the description:

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

@ansibot ansibot added support:core This issue/PR relates to code supported by the Ansible Engineering Team. and removed support:community This issue/PR relates to code supported by the Ansible community. labels Apr 29, 2020
@ansibot ansibot added the needs_triage Needs a first human triage before being processed. label May 16, 2020
@mkrizek mkrizek removed the needs_triage Needs a first human triage before being processed. label May 18, 2020
@s-hertel
Copy link
Contributor

Closing this for now, we'll keep this in mind if we redesign.

@ansible ansible locked and limited conversation to collaborators Jul 23, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affects_2.5 This issue/PR affects Ansible v2.5 feature This issue/PR relates to a feature request. support:core This issue/PR relates to code supported by the Ansible Engineering Team.
Projects
None yet
Development

No branches or pull requests

5 participants