You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Apr 20, 2021. It is now read-only.
Increase adoption through consistency, transparency and adaptability by returning the resource as currently configured on the device by way of the Ansible Facts system and making modules idempotent.
Focus on network operations
Problems
Implementing resource module with a Provider Role
Requires most of the command generation logic to be added in jinja2 template
For adding more options in module argspec requires adding complex programming logic within jinja2 template/yaml.
Write action plugin for each platform that would call platform specific _facts module to generate Facts with subset e.g, [interfaces]. This guarantees that we have unified ansible_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.
Generate Commands based on the diff between candidate and gathered facts.
If changed, generate after and before resource facts.
If not changed, generate only before resource facts.
The text was updated successfully, but these errors were encountered:
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.The text was updated successfully, but these errors were encountered: