[WIP] Inventory override of fact gathering action

[nitzmahone]

Proposal: Inventory override of fact gathering action

Author: Matt Davis @nitzmahone

Date: 2016/05/20

• Status: New
• Proposal type: Core fact behavior
• Targeted Release:
• Associated PR:
• Estimated time to implement: 3 days

Motivation

The current automatic fact gathering action (setup) must often be disabled for non-Unix target platforms, since it cannot be reliably overridden without breaking fact gathering for other platforms. Some platforms (eg, Windows) collude with a connection plugin to filter fact modules by file extension, but this behavior won't work for many other platforms (eg, networking) and may eventually break for Windows as well for non-Powershell setup modules or ssh-on-Windows.

Problems

What problems exist that this proposal will solve?

• Any target platform can easily provide a fact gathering action without collusion from a connection plugin
• Users needing custom fact gathering behavior can override built-in on a more granular per-host basis

Solution proposal

Add support for a new inventory variable, ansible_fact_action, which will allow inventory-level override of the default fact gathering action (setup). Normal action resolution will be performed on the named action, allowing for control-side execution of an action_plugin for fact gathering if desired- otherwise falling back to module resolution.

Testing

The new feature will require expanded unit/integration test coverage

Documentation

The final solution should include explicit documentation on how to write fact actions/modules, and how subsets (and any other fact-gathering alterations/args) are to be passed.

[privateip]

Does this proposal assume the module doesn't need any arguments passed to it in order to run?

[bcoca]

currently there is no way to pass arguments at 'gather_facts'

[nitzmahone]

Interesting point- IIRC most of @privateip's network modules require various extra args to work... I guess this comes back to needing some way to patch things through from inventory automatically. Unfortunately, the other ideas discussed around that wouldn't necessarily solve this case (eg, block-level inventory arg maps, adding playbook-level args to gather_facts), as we're allowing the setup module itself to be abstracted at inventory, so potentially different args needed per host.

[bcoca]

Thinking of the interface:

- hosts: network_devices
  gatherers:
     - ios
     - juniper
  ....

Would execute ios_facts and juniper_facts modules instead of the default setup

Still thinking on how to pass arguments, I'm back to the auth_plugins that would take care of this for all matching modules in a run, but they would have to run prior to fact gathering.

[nitzmahone]

I'd vote for less "magic" in the names (eg, don't turn "ios" into "ios_facts", just specify "ios_facts").

[bcoca]

ok, but i would still try to restrict it to _facts modules ... don't want to run 'parted' as part of fact gathering

[privateip]

At some point when is this even advantageous as opposed to just making your
first task a fact gathering task? Begs the question, do we even need to
have a way to "automagically" run fact collection as opposed to
transitioning to a model where including one (or more) fact gathering tasks
is just a best practice in playbook design? I haven't thought about it
long enough to propose the idea, but wanted to toss it out there for
consideration...

On Mon, Jul 25, 2016 at 2:03 PM, Brian Coca notifications@github.com
wrote:

ok, but i would still try to restrict it to _facts modules ... don't want
to run 'parted' as part of fact gathering

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#17 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZTokaE_synLWLHuOs_4DepBbo_pVQLks5qZPpWgaJpZM4IjbGr
.

[bcoca]

not as much on a single play, it is good for an override, my initial thought was being able to set this in config and/or inventory so as not to repeat on every play.

[nitzmahone]

I've never been a big fan of most automagic behavior, as it causes a lot of questions and corner cases, so you can imagine how I feel about this one. :)

[srgvg]

Explicit is better than implicit. Especially a best practice for Ansible 👍

[mikef-nl]

I like the idea of being able to add fact gatherers for custom facts. We're currently adding items for use with our CMDB in a separate module.

[bcoca]

ansible/ansible#31783

[nitzmahone]

implemented by ansible/ansible#49399 in Ansible 2.8 - closing