cisco.aci.aci_l3out module is NOT idempotent and so isn't behaving correctly

[JuanBH255]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

cisco.aci.aci_l3out module is NOT idempotent and so isn't behaving correctly. Every time I rerun the playbook it looks as if its not already created and a change is made.

• xxxx

Affected Module Name(s):

• aci_XXXXX

APIC version and APIC Platform

• V x.x.x and on-prem/cloud-aws/cloud-azure/all.

Collection versions

• cisco.aci 2.8.0

Output/ Error message

TASK [Create L3Outs] *****changed: [apic1 -> localhost] => (item=Creating L3Out --> Name: Juan-out-l3o || Description: Layer 3 Out for Juan || bind to Domain: l3out-dom || within VRF Name: cxn01-vrf || within Tenant Name: juan)

*

Expected Behavior

No change or an OK response.

*

Actual Behavior

*

Playbook tasks to Reproduce

- name: "Create L3Outs"
  cisco.aci.aci_l3out:
    host: "{{ ansible_host }}"
    username: "{{ username }}"
    password: "{{ password }}"
    validate_certs: "{{ validate_certs }}"
    tenant: "{{ item[0]['tenant_name'] }}"

    name: "{{ item[1]['l3out_name'] }}"
    description: "{{ item[1]['l3out_description'] | default(omit) }}"
    domain: "{{ item[1]['domain_name'] }}"
    vrf: "{{ item[1]['vrf_name'] }}"
    l3protocol: "{{ item[1]['l3protocol'] | default(omit) }}"
    route_control: "{{ item[1]['route_control'] | default(omit) }}"
    use_ssl: true
    state: present
  with_subelements:
    - "{{ tenants }}"
    - l3outs

        "l3outs": [
            {
                "l3out_name": "Juan-out-l3o",
                "vrf_name": "cxn01-vrf",
                "bridge_domains": [],
                "logical_n_profiles": [],
                "external_epgs": [],
                "l3out_description": "Layer 3 Out for Juan",
                "domain_name": "l3out-dom",
                "l3protocol": "bgp",
                "route_control": "export"
            }
        ]

*

Important Factoids

References

• 0000

[JuanBH255]

[akinross]

Hi @JuanBH255,

I m not sure what it is that you are sending for it to not be idempotent since it is running inside a loop. There are currently tests defined that would check idempotent behaviour, so would like to have a bit more details on this behaviour in order to have a better understanding of what is happening in your scenario. Could you provide logs by running your playbook with debug and high verbosity?

Also can you provide the aci version in the issue?

[JuanBH255]

Hi @akinross

The below has the same idempotent issues. I took out the loop and defined static values just like I was using in my json intent data. I tested this on ACI version 5.2(7g) and your DevNet ACI sandbox version 6.0(2h)

- name: "Create L3Outs"
  cisco.aci.aci_l3out:
    host: "{{ ansible_host }}"
    username: "{{ username }}"
    password: "{{ password }}"
    validate_certs: "{{ validate_certs }}"
    tenant: juan

    name: Juan-out-l3o
    description: Layer 3 Out for Juan
    domain: l3out-dom
    vrf: cxn01-vrf
    l3protocol: bgp
    route_control: export
    use_ssl: true
    state: present
  delegate_to: localhost

[akinross]

Hi @JuanBH255, had a quick look and this seems to be introduced by l3protocol behaviour. Will add to the todo list, thank you for raising the issue.

[akinross]

Hi @JuanBH255, added bug fix an to open PR for SR-MPLS support.

[JuanBH255]

Awesome Thank you @akinross ! Do you know when this fix will be released? If so, can you please provide an ETA?

[akinross]

Hi @JuanBH255,

This will depend on the speed of the review process and how many PRs are in the pipeline. Currently there are quite a few so it might take a bit of time.

[JuanBH255]

Hey @akinross @lhercot Happy New Year,

Was this update/fix implemented correctly? This is still an issue for me even after installing the latest aci collection.

ansible-galaxy collection install cisco.aci

Starting galaxy collection install process Process install dependency map Starting collection install process Downloading https://galaxy.ansible.com/api/v3/plugin/ansible/content/published/collections/artifacts/cisco-aci-2.8.0.tar.gz to /root/.ansible/tmp/ansible-local-93j3kllar/tmpn_thozxg/cisco-aci-2.8.0-ljkdti7s Installing 'cisco.aci:2.8.0' to '/root/.ansible/collections/ansible_collections/cisco/aci' Downloading https://galaxy.ansible.com/api/v3/plugin/ansible/content/published/collections/artifacts/ansible-netcommon-6.0.0.tar.gz to /root/.ansible/tmp/ansible-local-93j3kllar/tmpn_thozxg/ansible-netcommon-6.0.0-u77uzn81 cisco.aci:2.8.0 was installed successfully Installing 'ansible.netcommon:6.0.0' to '/root/.ansible/collections/ansible_collections/ansible/netcommon' Downloading https://galaxy.ansible.com/api/v3/plugin/ansible/content/published/collections/artifacts/ansible-utils-3.0.0.tar.gz to /root/.ansible/tmp/ansible-local-93j3kllar/tmpn_thozxg/ansible-utils-3.0.0-4o5edzrl ansible.netcommon:6.0.0 was installed successfully Installing 'ansible.utils:3.0.0' to '/root/.ansible/collections/ansible_collections/ansible/utils' ansible.utils:3.0.0 was installed successfully

[akinross]

Hi @JuanBH255,

Happy new year! It has been merged on the master branch but has not been released yet. Latest release is dating back from early November, thus this fix has not been included in 2.8.0. We will work on a release and will keep you updated on the progress.