-
Notifications
You must be signed in to change notification settings - Fork 23.7k
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
Configurable and parallel gather facts #49399
Conversation
Hi @bcoca, thank you for submitting this pull-request! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall process looks OK to me. Only big-picture question is if the async stuff is really worth it; unless a particular module is really slow, it adds a lot of moving parts and significant overhead (which may actually end up slower than serial direct execution in many cases).
Probably also needs explicit tests added to the Windows setup integration tests under win_setup
; the async stuff will probably work as-written, but we need to make sure...
81d0736
to
8a17c2e
Compare
also deal with the other 'setup specific' arguments
uses smart connection mapping
based on using 'network appliance' specific connection plugins
6a8999c
to
accda64
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let's discuss whether the connection map should be exposed or not, otherwise LGTM
@@ -1324,6 +1324,30 @@ ERROR_ON_MISSING_HANDLER: | |||
ini: | |||
- {key: error_on_missing_handler, section: defaults} | |||
type: boolean | |||
CONNECTION_FACTS_MODULES: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a good stopgap for networking until we have platform
, but I assume this would be superseded by that. Do we want to expose it to env/ini knowing that we'll need to deprecate it whenever we get around to platform, or just keep it as an internal detail for stuff that's shipped in the box for now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
since we cannot supply 'maps' that way .. i chose not to .. at least until ansible.config.yml
I'm fine with deprecating this once platform is out, but i don't see it as either/or proposition.
we could create per transport config .. but that does not need to happen right now, I would wait for user feedback.
Requested changes made, but have not re-reviewed at a higher level.
ios: ios_facts | ||
iosxr: iosxr_facts | ||
nxos: nxos_facts | ||
vyos: vyos_facts |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bcoca Will you please add frr: frr_facts
and junos: junos_facts
as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bcoca Does this facts gathering enable us to import ansible_facts
in modules like we currently have with collectors in module_utils/facts/compat.py
?
@trishnaguha i don't understand the question |
This comment has been minimized.
This comment has been minimized.
@bcoca If we do I was wondering if we have similar functionality here which would just execute the facts module whenever |
this is not touching the API, it just allows you to execute 1 or more facts modules |
Use a configurable list of multiple facts modules in parallel for fact gathering stage.
ISSUE TYPE
COMPONENT NAME
gather_facts