Open BGmot opened 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?
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,
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.
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
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>"
}
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?
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.
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 -/
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.
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.
I tried to code zone deletion the same way I do zone additions (works perfectly well) - please see below. Notes:
new_zones
has a list of zones to be created (with members)
zone_names_eff
has a list of all zones in effective configuration before
I generate zone_conf_name_new
based on our zone configuration name standard
name: Create new zones brocade_zoning_zone: credential: "{{ credential }}" vfid: -1 zones: "{{ new_zones }}"
name: Add new zones to the list of all zones set_fact: zone_names_eff: "{{ zone_names_eff + [ item.name ] }}" with_items: "{{ new_zones }}"
name: Create new configuration brocade_zoning_cfg: credential: "{{ credential }}" vfid: -1 cfgs:
As a result of the above, new zone is added only to zone configuration `zone_conf_name_new` which is effective zone configuration at the end of this play.
And I still don't understand why the same for zone deletion does not work.
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.
Did that resolve your problem?
No. You seem to be talking about different thing.
Supplying this via extravars:
After gathering facts via:
I see both zones in
brocade_zoning['defined-configuration']['zone']
and inbrocade_zoning['effective-configuration']['enabled_zone']
. However when I try to delete these zones using:I get:
Version 8.2.2d
Thank you.