brocade_zoning_cfg: -vvv output does still displays a populated "remove_list" although nothing will be removed in the switch config due to "members_add_only: True"

[tscheld]

When using "members_add_only: True" in a playbook to add some zones to a existing cfg and enabling it, the ansible-playbook -vvv output still show all previously configured zones in it's remove_list.
For examplle:
...
"post_list": [
{
"members": [
"Zone1"
],
"name": "FAB-A"
}
],
"remove_list": [
{
"members": [
"SVR12_STOR12"
],
"name": "FAB-A"
}
..

So the bahavior is changin with the members_add_only parameter, as nothing existing in the zoning configuration will be deleted, working as expected, but the output does not change when using members_add_only:True

Playbook:

• name: after zoning_zone.yml, add Zone3 to cfg1 by specifying all members and leave it enabled
  brocade_zoning_cfg:
  credential: "{{credential}}"
  vfid: -1
  cfgs: "{{cfgs}}"
  members_add_only: True
  active_cfg: FAB-A

[tscheld]

bash-5.1# ansible-galaxy collection list brocade.fos

/root/.ansible/collections/ansible_collections

Collection Version

---

brocade.fos 2.0.0

bash-5.1# python --version
Python 3.9.19

FOS version: Fabric OS: v9.2.1a

---

---

Copyright 2019 Broadcom. All rights reserved.

The term 'Broadcom' refers to Broadcom Inc. and/or its subsidiaries.

GNU General Public License v3.0+

(see COPYING or https://www.gnu.org/licenses/gpl-3.0.txt)

• hosts: all
  gather_facts: False
  collections:

  • brocade.fos

  vars:
  credential:
  fos_ip_addr: "{{fos_ip_addr}}"
  fos_user_name: "{{fos_user_name}}"
  fos_password: "{{fos_password}}"
  https: "{{fos_https}}"
  aliases:
  - name: Host1
  members:
  - aa:11:11:11:11:11:11:11
  - aa:22:22:22:22:22:22:22
  - bb:99:99:99:99:99:99:99
  zones:
  - name: Zone1
  members:
  - aa:44:44:44:44:44:44:44
  - aa:55:55:55:55:55:55:55
  - bb:99:99:99:99:99:99:99
  principal_members:
  - aa:aa:aa:aa:bb:bb:bb:bb
  - aa:aa:aa:aa:cc:cc:cc:CC
  - bb:bb:bb:bb:99:99:99:99
  cfgs:
  - name: FAB-A
  members:
  - Zone1

  tasks:

  • name: after zoning_zone.yml, add bb:99:99:99:99:99:99:99 to Host1 by specifying all members
    brocade_zoning_alias:
    credential: "{{credential}}"
    vfid: -1
    aliases: "{{aliases}}"

  • name: after zoning_zone.yml, add bb:99:99:99:99:99:99:99/bb:bb:bb:bb:99:99:99:99 to Zone3 by specifying all members
    brocade_zoning_zone:
    credential: "{{credential}}"
    vfid: -1
    zones: "{{zones}}"

  • name: after zoning_zone.yml, add Zone1 to cfg1 by specifying all members and leave it enabled
    brocade_zoning_cfg:
    credential: "{{credential}}"
    vfid: -1
    cfgs: "{{cfgs}}"
    members_add_only: True
    active_cfg: FAB-A

[Anson-CMC]

Same here. Although the play does well, the output made me scared.

[prasad-valmeti-broadcom]

Playbook generated the difference between the actual configuration and posted changes. In that process, it populates the posted list, remove list, and common list. If the members_add_only is set to True, the remove list is ignored. So, no removal occurs to the backend configuration.

This behavior is the same across all Ansible FOS releases. I hope this clarifies.
Do you still think it is an issue showing the remove list? Please let us know your thoughts on this.

[tscheld]

Prasad, thanks for your reply. Even it's more a cosmetic issue, I think it would help to change this:

• If nothings will be removed, why should we populate and display the remove list, it' scares people and seems wrong to me.
• Do we have the same bahavior when adding a member to an alias or zone? Haven't tried yet.
• As in larger environments this remove list can be quite huge, it makes ananlyzing the output for troubleshooting or just a quick check very hard.

just my 2 cents.

[mgoetze5]

Arguably you shouldn't use -vvv if you're easily scared. ;) But I agree it does often produce a lot of superfluous output that makes it hard to understand what the actual problem is.

[prasad-valmeti-broadcom]

Sure, got your point; we will address it in the next release.
We can put it in the external GitHub develop branch if you want any immediate fix.
Please let us know your thoughts on this.

[tscheld]

thanks Prasad!

As it's more a cosmetic issue, there's no need to put it in the extermanl Github development branch I think.