We used the logic of converting the lun-id > 255 to hex in initialize_connection method of driver while passing target info to confirm the reason to fail. Attach volume works fine.
Is this workaround correct ??
Since the behavior is scci report luns standard and any array would face the same issue I do feel the logic has to go with os-brick instead of hex convert util in all drivers to check with hex if it fails to find device with lun-id > 255.
Also symlimks to device in /dev/disk/by-path is little unpredictable. I could not replicate the issue but have seen ip-192.168.5.100:3260-iscsi-iqn.1989-10.jp.co.xxx:storage.ttsp.2ec7fdda.ff5c4a16.0-lun-0x0200000000000000-part1 couple of times. "-part1" appeared in the end and even this could make attach volume fail for the reason device not found.
/dev/disk/by-path isn't risky for attach volume ??
We used the logic of converting the lun-id > 255 to hex in initialize_ connection method of driver while passing target info to confirm the reason to fail. Attach volume works fine.
Is this workaround correct ??
Since the behavior is scci report luns standard and any array would face the same issue I do feel the logic has to go with os-brick instead of hex convert util in all drivers to check with hex if it fails to find device with lun-id > 255.
Also symlimks to device in /dev/disk/by-path is little unpredictable. I could not replicate the issue but have seen ip-192. 168.5.100: 3260-iscsi- iqn.1989- 10.jp.co. xxx:storage. ttsp.2ec7fdda. ff5c4a16. 0-lun-0x0200000 000000000- part1 couple of times. "-part1" appeared in the end and even this could make attach volume fail for the reason device not found.
/dev/disk/by-path isn't risky for attach volume ??