Gittins
commented
1 year ago Had a play at debugging the playbook with "-vvv" and spotted that the working resource modules were being redirected to the actual underlying network provider module name:
TASK [Fetch config for working modules] *****************************************************************************************************
task path: /home/anthonygittins/venv_ansible/ansible/network_resource_manager_test_playbook.yml:29
redirecting (type: modules) cisco.ios.acl_interfaces to cisco.ios.ios_acl_interfaces
ok: [ciscoao_latest_iosxe] => (item=acl_interfaces) => {
"ansible_connection": "ansible.netcommon.network_cli",
"ansible_loop_var": "item",
"ansible_network_os": "cisco.ios.ios",
"changed": false,
"gathered": {},
"invocation": {
"module_args": {
"config": null,
"running_config": null,
"state": "gathered"
}
},
"item": "acl_interfaces",
"resource_module_name": "cisco.ios.acl_interfaces"
}Specifically redirecting cisco.ios.acl_interfaces to cisco.ios.ios_acl_interfaces (the actual name of the module), which got me wondering if the redirecting wasn't working for one or all of the failing resource modules. To check this I changed the resource name provided in the loop to be the actual module it should go to, namely ios_bgp_address_family, like this:
- name: Fetch config for failing modules
ansible.netcommon.network_resource:
# os_name: "{{ network_resource_info.ansible_network_os }}"
name: "{{ item }}"
state: gathered
loop:
- ios_bgp_address_family
- ios_ospf_interfaces
- ios_ospfv2
- ios_ospfv3
ignore_errors: true
register: failing_module_infoAnd what do you know, the task no longer fails:
TASK [Fetch config for failing modules] *****************************************************************************************************
task path: /home/anthonygittins/venv_ansible/ansible/network_resource_manager_test_playbook.yml:73
ok: [ciscoao_latest_iosxe] => (item=ios_bgp_address_family) => {
"ansible_connection": "ansible.netcommon.network_cli",
"ansible_loop_var": "item",
"ansible_network_os": "cisco.ios.ios",
"changed": false,
"gathered": {
"address_family": [
{
"afi": "ipv4"
}
],
"as_number": "65"
},
"invocation": {
"module_args": {
"config": null,
"running_config": null,
"state": "gathered"
}
},
"item": "ios_bgp_address_family",
"resource_module_name": "cisco.ios.ios_bgp_address_family"
}
ok: [ciscoao_latest_iosxe] => (item=ios_ospf_interfaces) => {
"ansible_connection": "ansible.netcommon.network_cli",
"ansible_loop_var": "item",
"ansible_network_os": "cisco.ios.ios",
"changed": false,
"gathered": [
{
"name": "GigabitEthernet1"
},
{
"name": "GigabitEthernet2"
},
{
"name": "GigabitEthernet3"
}
],
"invocation": {
"module_args": {
"config": null,
"running_config": null,
"state": "gathered"
}
},
"item": "ios_ospf_interfaces",
"resource_module_name": "cisco.ios.ios_ospf_interfaces"
}
ok: [ciscoao_latest_iosxe] => (item=ios_ospfv2) => {
"ansible_connection": "ansible.netcommon.network_cli",
"ansible_loop_var": "item",
"ansible_network_os": "cisco.ios.ios",
"changed": false,
"gathered": {},
"invocation": {
"module_args": {
"config": null,
"running_config": null,
"state": "gathered"
}
},
"item": "ios_ospfv2",
"resource_module_name": "cisco.ios.ios_ospfv2"
}
ok: [ciscoao_latest_iosxe] => (item=ios_ospfv3) => {
"ansible_connection": "ansible.netcommon.network_cli",
"ansible_loop_var": "item",
"ansible_network_os": "cisco.ios.ios",
"changed": false,
"gathered": {},
"invocation": {
"module_args": {
"config": null,
"running_config": null,
"state": "gathered"
}
},
"item": "ios_ospfv3",
"resource_module_name": "cisco.ios.ios_ospfv3"
}
TASK [Debug network_resource_info] **********************************************************************************************************
task path: /home/anthonygittins/venv_ansible/ansible/network_resource_manager_test_playbook.yml:86
ok: [ciscoao_latest_iosxe] => {
"failing_module_info": {
"changed": false,
"msg": "All items completed",
"results": [
{
"ansible_connection": "ansible.netcommon.network_cli",
"ansible_loop_var": "item",
"ansible_network_os": "cisco.ios.ios",
"changed": false,
"failed": false,
"gathered": {
"address_family": [
{
"afi": "ipv4"
}
],
"as_number": "65"
},
"invocation": {
"module_args": {
"config": null,
"running_config": null,
"state": "gathered"
}
},
"item": "ios_bgp_address_family",
"resource_module_name": "cisco.ios.ios_bgp_address_family"
},
{
"ansible_connection": "ansible.netcommon.network_cli",
"ansible_loop_var": "item",
"ansible_network_os": "cisco.ios.ios",
"changed": false,
"failed": false,
"gathered": [
{
"name": "GigabitEthernet1"
},
{
"name": "GigabitEthernet2"
},
{
"name": "GigabitEthernet3"
}
],
"invocation": {
"module_args": {
"config": null,
"running_config": null,
"state": "gathered"
}
},
"item": "ios_ospf_interfaces",
"resource_module_name": "cisco.ios.ios_ospf_interfaces"
},
{
"ansible_connection": "ansible.netcommon.network_cli",
"ansible_loop_var": "item",
"ansible_network_os": "cisco.ios.ios",
"changed": false,
"failed": false,
"gathered": {},
"invocation": {
"module_args": {
"config": null,
"running_config": null,
"state": "gathered"
}
},
"item": "ios_ospfv2",
"resource_module_name": "cisco.ios.ios_ospfv2"
},
{
"ansible_connection": "ansible.netcommon.network_cli",
"ansible_loop_var": "item",
"ansible_network_os": "cisco.ios.ios",
"changed": false,
"failed": false,
"gathered": {},
"invocation": {
"module_args": {
"config": null,
"running_config": null,
"state": "gathered"
}
},
"item": "ios_ospfv3",
"resource_module_name": "cisco.ios.ios_ospfv3"
}
],
"skipped": false
}
}
PLAY RECAP **********************************************************************************************************************************
ciscoao_latest_iosxe : ok=6 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=1 So there seems to be some sort of issue with the mapping and searching of the resource names that are pulled back using the ansible.netcommon.network_resource module.
Hope this helps identify and fix the issue.
SUMMARY
Using the ansible.netcommon.network_resource module against a working, from Ansible's point of view, network device (Cisco IOS, CSR1000V) fails when specific resource modules, that are known to be available for the device, are referenced.
The resource modules causing the failure have been identified as:
ISSUE TYPE
COMPONENT NAME
ansible.netcommon.network_resource
ANSIBLE VERSION
COLLECTION VERSION
CONFIGURATION
OS / ENVIRONMENT
Targeted network device info:
The below table collates the device's hardware information:
The following table collates the device's software information
STEPS TO REPRODUCE
Run the below playbook against the Cisco Always-On latest IOSXE device:
ciscoao_latest_iosxe: ansible_host: sandbox-iosxe-latest-1.cisco.com ansible_connection: ansible.netcommon.network_cli ansible_network_os: cisco.ios.ios ansible_user: developer ansible_password: C1sco12345
EXPECTED RESULTS
The first task in the playbook registers all the available modules for the device/host being targeted, with the subsequent task outputting them so we can see what's available.
The "Fetch config for working modules" task contains a partial list of the modules found to be available, which it runs through, as expected. The first 2 modules in the list work without issue and their outputs are collected. The last module "vlans" fails with an appropriate error message, which I have no real issue with (there are no vlans on the device, so this could be the cause).
However, the "Fetch config for failing modules" task contains the list of modules I've isolated down which cause the task to fail with a python based error, when targeting either 1 or all of them. This is the issue that is completely breaking things for me and I'd like help understanding and, if possible, fixing.
ACTUAL RESULTS
The "Fetch config for failing modules" task fails with a python error message as seen below: