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.
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-3c530893d7 7f 0 ae4ad93a1d43408 7851e3319bc8245 5f - - -] 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 volume. drivers. emc.emc_ vmax_masking [req-74a593d8- 7af9-4a75- bdc8-3c530893d7 7f 0 ae4ad93a1d43408 7851e3319bc8245 5f - - -] Initiator Name(s) [u'c0507606a32c 0656', u'c0507606a32c0 657', u'c0507606a32c0 654', u'c0507606a32c0 655'] are not on array SYMMETRIX+ 000198700498 volume. drivers. emc.emc_ vmax_masking [req-74a593d8- 7af9-4a75- bdc8-3c530893d7 7f 0 ae4ad93a1d43408 7851e3319bc8245 5f - - -] Cannot create or find an initiator group with name OS-csky_ npiv5-05123912- 00000005- F-IG
2015-01-08 11:59:17.238 12858 ERROR cinder.
2015-01-08 11:59:17.239 12858 ERROR cinder.
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-3c530893d7 7f 0 ae4ad93a1d43408 7851e3319bc8245 5f - - -] 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 zonemanager. drivers. brocade. brcd_fc_ san_lookup_ service [req-74a593d8- 7af9-4a75- bdc8-3c530893d7 7f 0 ae4ad93a1d43408 7851e3319bc8245 5f - - -] Device map for SAN context: {'a': {'target_ port_wwn_ list': ['50000973f007c 944', '50000973f007c905', '50000973f007c985', '50000973f007c9 45'], '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
2015-01-08 11:57:47.734 12858 DEBUG cinder.
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.