Uncaught error when trying to change the default VFID

[mgoetze5]

I tried to change the default VFID on a Brocade G720 running FOS 9.1.1c like so:

- name: Assign ports to nondefault virtual switchs
  brocade.fos.brocade_fibrechannel_logical_switch_fibrechannel_logical_switch:
    credential: "{{credential}}"
    vfid: -1
    logical_switches: "{{ logical_switch_config }}"

with

logical_switch_config:
  - fabric_id: 10
    default_switch: true
    base_switch_enabled: 0
    ficon_mode_enabled: 0
    logical_isl_enabled: 1
    port_member_list:
      port_member:
        - "0/0"
        - "0/1"
        - "0/2"
        - "0/3"
        - "0/4"
        - "0/5"
        - "0/6"
        - "0/7"
        - "0/8"
        - "0/9"
        - "0/10"
        - "0/11"
        - "0/12"
        - "0/13"
        - "0/14"
        - "0/15"
        - "0/16"
        - "0/17"
        - "0/18"
        - "0/19"
        - "0/20"
        - "0/21"
        - "0/22"
        - "0/23"
        - "0/24"
        - "0/25"
        - "0/26"
        - "0/27"
        - "0/28"
        - "0/29"
        - "0/30"
        - "0/31"
        - "0/32"
        - "0/33"
        - "0/34"
        - "0/35"
        - "0/36"
        - "0/37"
        - "0/38"
        - "0/39"
        - "0/40"
        - "0/41"
        - "0/42"
        - "0/43"
        - "0/44"
        - "0/45"
        - "0/46"
        - "0/47"
        - "0/48"
        - "0/50"
        - "0/52"
        - "0/54"
        - "0/56"
        - "0/58"
        - "0/60"
        - "0/62"
  - fabric_id: 128
    default_switch: false
    base_switch_enabled: 0
    ficon_mode_enabled: 0
    logical_isl_enabled: 0
    port_member_list:
      port_member:
        - "0/49"
        - "0/51"
        - "0/53"
        - "0/55"
        - "0/57"
        - "0/59"
        - "0/61"
        - "0/63"

This works on a switch where I have previously executed lscfg --change 128 -newfid 10. However on a switch with factory default settings I get a 405 response with the following REST error:

  "POST_resp_data": {
    "errors": {
      "@xmlns": "urn:ietf:params:xml:ns:yang:ietf-restconf",
      "error": {
        "error-type": "application",
        "error-tag": "operation-not-supported",
        "error-app-tag": "Error",
        "error-message": "Invalid read-only attribute specified in request",
        "error-info": {
          "error-code": "16717063",
          "error-module": "cal"
        }
      }
    }
  }

Expected behaviour is then for ansible to mark the task as failed and abort execution of the playbook, however ansible marked the task as OK and continued execution of the playbook.

PS is there any way to change the VFID of the default LS via API?

[mgoetze5]

BTW this is a similar issue to #95 where there is also incongruence between the REST-level and the ansible-level failure/success identification.

[prasad-valmeti-broadcom]

Hi, Ansible compares the switch configuration with the playbook configuration, if both are the same for that attribute/object then the PATCH/POST request is not sent. As discussed #95, is not reproducible with the v1.3.3 Ansible FOS version and 9.2.1 switch release. Please let us know if you see this issue with the latest Ansible version. Regards, Prasad

[mgoetze5]

Well in this case a POST was sent and the switch configuration did not change as specified. This is with brocade.fos 1.3.3 from galaxy.

[prasad-valmeti-broadcom]

logical_switch_config:

• fabric_id: 10 default_switch: true

This is a ready-only parameter you can't use it for configuration. There is no REST equivalent for CLI command "lscfg --change 128 -newfid 10" If you remove default_switch from the configuration, it will create a logical switch.

[prasad-valmeti-broadcom]

In case it needs support through REST, please raise RFE through PM. If there are no further issues, please suggest if we can close this issue.

[mgoetze5]

@prasad-valmeti-broadcom I understand that this is not supported by REST and therefore expected to fail at the REST level. But the problem is that once again REST level errors are not showing up as errors at the Ansible level. As I said in the initial report

Expected behaviour is then for ansible to mark the task as failed and abort execution of the playbook, however ansible marked the task as OK and continued execution of the playbook.

[prasad-valmeti-broadcom]

Thanks for the update. This issue will be addressed in Ansible FOS 2.0.0. In case if you want to take care in your branch, please change the following file with the changes mentioned below: diff --git a/utils/brocade_connection.py b/utils/brocade_connection.py index 2ddc390..d6f1a05 100644 --- a/utils/brocade_connection.py +++ b/utils/brocade_connection.py @@ -136,6 +136,7 @@ def exit_after_login(fos_ip_addr, https, auth, result, module, timeout): :return: 0 :rtype: int """

• result["failed"] = True logout(fos_ip_addr, https, auth, result, timeout) module.exit_json(**result) return 0

  Hope this will address the issue that is reported.