brocade / ansible

55 stars 33 forks source link

Cannot delete zones #100

Open BGmot opened 2 years ago

BGmot commented 2 years ago

Supplying this via extravars:

zones_to_delete:
  - name: bqr_043_pg4
  - name: bqr_143_pg4

After gathering facts via:

    - name: Get all zone configurations
      brocade_facts:
        credential: "{{credential}}"
        vfid: -1
        gather_subset:
          - brocade_zoning

I see both zones in brocade_zoning['defined-configuration']['zone'] and in brocade_zoning['effective-configuration']['enabled_zone']. However when I try to delete these zones using:

- name: Delete zones
  brocade_zoning_zone:
    credential: "{{ credential }}"
    vfid: -1
    zones_to_delete: "{{ zones_to_delete }}"

I get:

{
    "DELETE_url": "http://********/rest/running/zoning/defined-configuration",
    "GET_url": "http://********/rest/running/zoning/defined-configuration/zone",
    "PATCH_resp_code": 400,
    "PATCH_resp_data": {
        "errors": {
            "@xmlns": "urn:ietf:params:xml:ns:yang:ietf-restconf",
            "error": {
                "error-app-tag": "Error",
                "error-info": {
                    "error-code": "-1",
                    "error-module": "zone"
                },
                "error-message": "\"bqr_043_pg4\" not found",
                "error-path": "/effective-configuration/",
                "error-tag": "Operation-failed",
                "error-type": "protocol"
            }
        }
    },
    "PATCH_resp_reason": "Bad Request",
    "PATCH_url": "http://********/rest/running/zoning/effective-configuration",
    "POST_url": "http://********/rest/logout",
    "changed": false,
    "delete_list": [{
        "name": "bqr_043_pg4"
    }, {
        "name": "bqr_143_pg4"
    }],
    "msg": "CFG ENABLE failed",
    "patch_resp_data": "",
    "zone_str": "<defined-configuration><zone><zone-name>bqr_043_pg4</zone-name></zone><zone><zone-name>bqr_143_pg4</zone-name></zone></defined-configuration>"
}

Version 8.2.2d

Thank you.

prabhu-broadcom commented 2 years ago

Hi, Zone delete operation from effective configuration has two steps as mentioned below. It appears that the second step was not executed in this case. Can you check it?

  1. Delete zone from zone database
  2. Remove zone from cfg member list

There are samples available for reference in GIT. This is the playbook to create/delete members and its common for all the objects (alias. cfg, zone).

https://github.com/brocade/ansible/blob/master/zoning_zone_add_remove.yml

We use this below one to setup the master database prior to executing zoning_zone_add_remove.yml.

https://github.com/brocade/ansible/blob/master/zoning_zone.yml

If you look into zoning_zone_add_remove.yml playbook, it adds "Zone4", removes "Zone1/Zone2" (based on the diff from current zone db and new one) and then enables cfg1. To remove the zone member from cfg, the below task is required in the playbook. Can you add this similar task for bqr_043_pg4/bqr_143_pg4 zones and try it?

cfgs:
      - name: cfg1
        members:
          - Zone4

Thanks,

BGmot commented 2 years ago

Hi, In zoning_zone_add_remove.yml we do not delete any zones from zone database (defined zone config), it just removes zones Zone1/Zone2 from effective database but zones themselves stay provisioned in defined zone config. I went into the source code and found following. brocade_zoning_zone module with zones_to_delete zones defined, makes an API call to actually delete the zones from defined database and immediately tries to activating changes in current effective zone config. The error I posted is related to the second action - zone enable fails on effective zone config, and it is reasonable the effective zone config has zones list not modified, i.e. containing zones we just deleted thus it fails to activate saying "error-message": "\"bqr_043_pg4\" not found" My current workaround is: 1) Get the zones list from current effective zone config 2) Remove zones defined in zones_to_delete list from the list we got in 1) 3) Create new zone config with list of zones from 2) 4) Execute my code

    - name: Get all zone configurations
      brocade_facts:
        credential: "{{credential}}"
        vfid: -1
        gather_subset:
          - brocade_zoning

It works and I have new effective zone config without these zones and these zones permanently gone from defined config (all zones database). I have lots of doubts here... I am not a Storage guru I am just an automation guy doing work for Storage team. So if I delete these zone the way I described above I will not be able to activate any older zone config that references these zones. I am not sure whether it is fine or not for Storage team. On the other hand, if we don't ever delete old zones from defined zone config it will never be cleaned up and grow endlessly.

My surprise with brocade_zoning_zone module is that it will always activate changes, you can't prevent that. But what if I want to make several changes - delete some zones, add some zones, change some zones members and who knows what else. And then when I am done I would like to activate new zone config with all these changes in one shot.

prabhu-broadcom commented 2 years ago

Hi, The defined configurations zones can be saved with cfgsave operations and it does not require explicit cfg activation. This case is mishandled in the utils code where it always activates the cfg name retrieved either from playbook or switch. We have fixed this cfg activation failure in the side branch - documentation_attribute_content_change. Please check and let us know if it works fine.

Thanks

BGmot commented 2 years ago

Hi, I am sorry for the delay, just saw this message and promise to more carefully follow comments on this issue. I tried to apply your patch but getting this:

{
    "DELETE_url": "http://********/rest/running/brocade-zone/defined-configuration",
    "GET_url": "http://********/rest/running/brocade-zone/defined-configuration/zone",
    "PATCH_resp_code": 400,
    "PATCH_resp_data": {
        "errors": {
            "@xmlns": "urn:ietf:params:xml:ns:yang:ietf-restconf",
            "error": {
                "error-app-tag": "Error",
                "error-info": {
                    "error-code": "-1",
                    "error-module": "zone"
                },
                "error-message": "\"bqr_051_pg5\" not found",
                "error-path": "/effective-configuration/",
                "error-tag": "Operation-failed",
                "error-type": "protocol"
            }
        }
    },
    "PATCH_resp_reason": "Bad Request",
    "PATCH_url": "http://********/rest/running/brocade-zone/effective-configuration",
    "POST_url": "http://********/rest/logout",
    "changed": false,
    "delete_list": [{
        "name": "bqr_051_pg5"
    }],
    "fos_version": "v8.2.3b",
    "msg": "CFG SAVE failed",
    "patch_resp_data": "",
    "zone_str": "<defined-configuration><zone><zone-name>bqr_051_pg5</zone-name></zone></defined-configuration>"
}
BGmot commented 2 years ago

Again I am not a storage expert just trying to think here. Suppose I have following. Zones:

- name: zone1
  members:
  - wwwn11
  - wwwn12
- name: zone2
  members:
  - wwwn21
  - wwwn22
- name: zone3
  members:
  - wwwn31
  - wwwn32

Zone configuratios:

- name: zoneconf1
  members:
  - zone1
  - zone2
- name: zoneconf2
  members:
  - zone2
  - zone3

Effective zone config is zoneconf2 at the moment. Goal: delete zone2. If with this code I delete this zone

- name: Delete zones
  brocade_zoning_zone:
    credential: "{{ credential }}"
    vfid: -1
    zones_to_delete:
    - name: zone2

then it should remove it from zoneconf2 which is effective at the moment has a reference to this zone so it can't be done. Is that correct? In which "namespace" this operation should happen? (by namespace I mean zone config) or cfg save should save it "somewhere" and then I create new zone configuration without this zone and activate it? How is it supposed to work?

dbond007 commented 2 years ago

I am just starting with this (brocade and ansible), so may be wrong, or misinterpreting what you are trying to do. But from what I can see, the zone delete doesn't do anything special, it just removes the zone. So, if that zone is in use, you will need to first remove the zone from config then remove the zone itself. It would be just like you are doing it in the shell or gui.

BGmot commented 2 years ago

Well the whole point of automation is to move away from shell or gui -))) I can code it myself I just need to understand the logic. Storage management automation is quite different from regular servers -/

dbond007 commented 2 years ago

You are misunderstanding what I meant. The process that you would need to do is the same as if it was in the shell. When zoning a new system, you would first create an alias, then add that alias into a zone with the ports for storage system, then add it to the config, saving and applying that configuration. If you were wanting to remove that system, you would need to reverse it. First removing from the configuration, then deleting the zone, then deleting the alias.

BGmot commented 2 years ago

Sorry for misunderstanding. I don't have access to either shell or GUI, I am not from storage team. Do you know a set of shell commands to delete a zone? I could try to translate into Ansible.

BGmot commented 2 years ago

I tried to code zone deletion the same way I do zone additions (works perfectly well) - please see below. Notes:

dbond007 commented 2 years ago

If you want to add to the current config, you would (from reading the documentation), do the following, if you just wanted to add to the the current list of member (adding members_add_only: True):

- name: Create new configuration
  brocade_zoning_cfg:
    credential: "{{ credential }}"
    vfid: -1
    members_add_only: True
    cfgs:
      - name: "{{ zone_conf }}"
        members: "{{ new_zones }}"
    active_cfg: "{{ zone_conf }}"

to remove, you would use, members_remove_only: True then what ever you set would remove only them, no need to calculate the difference.

This hasnt been tested by me, just from looking at the documents, so i could be wrong.

dbond007 commented 2 years ago

Did that resolve your problem?

BGmot commented 2 years ago

No. You seem to be talking about different thing.