Xing,
I have reviewed the patch and tested it in our environment. The changes that add new utility methods and make use of them seem good and more correct than what was there before. However, I ran into two major issues:

(1) Our NPIV attach request did not just have a problem with auto-zoning...it failed much earlier than that when the Initiator Group needed to be created. That failure still happens. Here is a snippet of the logging:

2015-01-08 11:59:17.237 12858 DEBUG cinder.volume.drivers.emc.emc_vmax_masking [req-74a593d8-7af9-4a75-bdc8-3c530893d77f 0 ae4ad93a1d434087851e3319bc82455f - - -] The found hardware IDs are : []  _get_storage_hardware_id_instance_names /usr/lib/python2.6/site-packages/cinder/volume/drivers/emc/emc_vmax_masking.py:540
2015-01-08 11:59:17.238 12858 ERROR cinder.volume.drivers.emc.emc_vmax_masking [req-74a593d8-7af9-4a75-bdc8-3c530893d77f 0 ae4ad93a1d434087851e3319bc82455f - - -] Initiator Name(s) [u'c0507606a32c0656', u'c0507606a32c0657', u'c0507606a32c0654', u'c0507606a32c0655'] are not on array SYMMETRIX+000198700498
2015-01-08 11:59:17.239 12858 ERROR cinder.volume.drivers.emc.emc_vmax_masking [req-74a593d8-7af9-4a75-bdc8-3c530893d77f 0 ae4ad93a1d434087851e3319bc82455f - - -] Cannot create or find an initiator group with name OS-csky_npiv5-05123912-00000005-F-IG

The VMAX does not know about the NPIV initiator wwpns. For other storage devices we support, we basically do operations that tell the backend, "Here are the initiator WWPNs. You don't know about them yet, so please add them to your database and mask them in for volume XX access."  But for VMAX, the cinder driver flow raises the above exception when it cannot locate the WWPNs in the VMAX/ECOM database.

(2) It is unclear to me how the lookup service would know about the initiator WWPNs either. The defect description says "With this fix, the initiator is no longer required to log into the fabric ahead of time." I tried moving the lookup service call to code prior to the common.initialize_connection() processing. The logging shows that it does not know about the initiator WWPNs:

2015-01-08 11:57:47.733 12858 DEBUG cinder.zonemanager.drivers.brocade.brcd_fc_san_lookup_service [req-74a593d8-7af9-4a75-bdc8-3c530893d77f 0 ae4ad93a1d434087851e3319bc82455f - - -] No initiators are in the nameserver for SAN a get_device_mapping_from_network /usr/lib/python2.6/site-packages/cinder/zonemanager/drivers/brocade/brcd_fc_san_lookup_service.py:180
2015-01-08 11:57:47.734 12858 DEBUG cinder.zonemanager.drivers.brocade.brcd_fc_san_lookup_service [req-74a593d8-7af9-4a75-bdc8-3c530893d77f 0 ae4ad93a1d434087851e3319bc82455f - - -] Device map for SAN context: {'a': {'target_port_wwn_list': ['50000973f007c944', '50000973f007c905', '50000973f007c985', '50000973f007c945'], 'initiator_port_wwn_list': []}} get_device_mapping_from_network /usr/lib/python2.6/site-packages/cinder/zonemanager/drivers/brocade/brcd_fc_san_lookup_service.py:187

In my case, I only have one fabric "a", and the flow seems to be what I would expect - none of the four initiators are in the nameserver because the switch doesn't know about them since they aren't yet logged into the fabric.

Am I missing something here? Thanks.