Open trishnaguha opened 5 years ago
Since the operational and configuration facts are different can we have separate top level keys to store the facts? For eg.
{
ansible_net_operational:
{
interfaces: [...],
bgp: [...]
}
ansible_net_configuration:
{
interfaces: [...],
bgp: [....]
}
}
This also is in sync with the two prompt modes supported by most vendors (operational and configuration mode) on the device.
The facts extracted from show commands (except show running-config
) executed in the operational mode (eg. show interfaces) can be stored under ansible_net_operational
and the facts extracted from show commands executed under config mode including show running-config
can be stored under ansible_net_configuration
key.
The proposed resource modules will provide the individual configuration facts in the module arspec pattern that can be stored in ansible_net_configuration
key within ansible_facts
.
Proposal: network interfaces resource module
Author: Trishna Guha <@trishnaguha>
Date: 2019-03-06
Motivation
Problems
Implementing resource module with a Provider Role
Solution Proposal
Model
Module has a parent “config” and “operation” key
"State"
Playbook
Return
Gathered Facts Facts gathered when
gather_facts
orgather_subset
is enabled.Implementation
modules/network/{{ ansible_network_os }}/{{ ansible_network_os }}_interfaces.py
module_utils/network/{{ ansible_network_os }}/config/interfaces/interfaces.py
module_utils/network/{{ ansible_network_os }}/facts/interfaces/interfaces.py
[interfaces]
. This guarantees that we have unifiedansible_facts
data model across both facts generated at play level or task level in module calls and do not need to get config and parse within the module by just reusing facts implementation.after
andbefore
resource facts.before
resource facts.