Existing volume detach fails after modifying the zoning_mode=fabric from none

[Shanthakumar K]

Existing volume detach fails modify the zoning_mode=fabric from none

Steps to reproduce:
1. Create and attach the volume to instance with zoning_mode=none
2. modify the cinder.conf to support zoning_mode=fabric
3. detach the volume that's already attached part of step one

This usecase is valid in prodcution env, when customer started fc volumes with pre-zoning later moving to auto-zoning.

[Kurt Martin (kurt-f-martin)]

Please provide the version of OpenStack that you are using and logs. The way the FCZM works currently is it required to create the zone so it can find them later at detach time. It uses a naming convention for this reason, so if you created the zone by hand outside of OpenStack, and then enabled FCZM the alias name will not be found. Marking Invalid, if any thing this sound like an enhancement.

[Shanthakumar K (shantha-kumar)]

Thanks for the response and sorry for the delay.

Does it mean, during the migration of FCZM from pre-zoning all the volumes attached during pre-zoning should be removed and attached again or how it needs to be addressed.

[Kurt Martin (kurt-f-martin)]

I'm fairly ceratin that is the case but checking with Angela from Brocade to verify. I'm not not sure that the FCZM can deal with predefined zones that it did not create.

[Angela Smith (aallen-m)]

Kurt has described the behavior correctly. FCZM cannot handle predefined zones. When a detach operation comes in, the FCZM is looking for the zone name with the format specified in Openstack attach volume call. If that name is not found, no zoning operation is performed on the FC switch.

[Shanthakumar K (shantha-kumar)]

Thanks Angela, I understand the flow as described by kurt.

My question is how can we handle this ?

[Kurt Martin (kurt-f-martin)]

Seems the only solution available now is the following;
1. Detach all volumes from host that were pre-zoned
2. Delete the pre-defined zone(s) from the fabric
3. Enable FCZM
4. Reattach all volumes

According to Angela(Brocade)To support this scenario, FCZM would have to be reworked to not look up by zone name, but by zone members, which would increase the time required to process the call, somewhat drastically she thinks, as we'd have to process the entire defined zone database

[Walt Boring (walter-boring)]

I would add a FCZM config option to enable a fallback to searching for the zone by members. There are definite downsides to enabling this, so it should be documented as a last resort, but the individual drivers can choose to honor the setting or not.

[Sean McGinnis (sean-mcginnis)]

Unassigning due to no activity.

[Angela Smith (aallen-m)]

Really, this is a Won't Fix item, but I cannot set that as the status, so set to Invalid for now.

This request is for a workaround enhancement to add a flag and do lookup by zone membership rather than by name. Implementing this would degrade performance and goes against best practices for FC SAN management. When a user is migrating from one mgmt application(or manual mgmt of the FC SAN) to a new mgmt application, they should clear out the zone DB and rebuild using the new mgmt app. In this case, there is one other alternative approach. Prior to enabling zoning in Cinder, detach the volumes first. Then enable zoning, and reattach any volumes that should remain. This will establish the zones through Openstack client, thus allowing Openstack to manage those zones.

[Walt Boring (walter-boring)]

What would be the issue of catching the failure to find the zone and ignoring that failure at zone removal in the @RemoveFCZone decorator?

We should investigate the possibility of allowing the detach to go on, ignore the failure to lookup the zone and simply log a warning.

The scenario here is most likely that the switch was manually zoned prior to the attachment, in which case the FCZM won't find the zone by name.

[Angela Smith (aallen-m)]

I am unable to reproduce error scenario on this operation on master or Liberty. If this is still reproducible, please include log files with debug enabled for Cinder. Thanks