<div dir="ltr">Hi Brano,<div><br></div><div>I apologize for reviving an old thread.</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 20, 2013 at 4:39 AM, Brano Zarnovican <span dir="ltr"><<a href="mailto:zarnovican@gmail.com" target="_blank">zarnovican@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi devs,<br>
<br>
we are using backend iSCSI provider (Netapp) which is mapping<br>
Openstack volumes to iSCSI LUNs. This mapping is not static and<br>
changes over time. For example when the volume is detached then his<br>
LUN id becomes unused. After a while a _different_ volume may get the<br>
same LUN id, as Netapp is recycling them. This is expected behavior..<br>
<br>
As a result, there may be entries in "block_device_mapping" with<br>
identical connection_info..<br>
connection_info: {"driver_volume_type": "iscsi", "data":<br>
{"target_lun": "5", .. "target_iqn":<br>
"iqn.1992-08.com.netapp:node.netapp02", volume_id": 1806}}<br>
connection_info: {"driver_volume_type": "iscsi", "data":<br>
{"target_lun": "5", .. "target_iqn":<br>
"iqn.1992-08.com.netapp:node.netapp02", volume_id": 2227}}<br>
Zero or one of them may be attached, the rest is in detached state.<br>
<br>
As a fix to address #1112483, I'm deleting the device when it is being<br>
disconnected (echo 1 > /sys/block/sdg/device/delete).<br>
<br>
Trouble is that OpenStack seems to expect the disconnect_volume to be<br>
idempotent (_cleanup() method). That is, calling disconnect_volume on<br>
detached volume will do nothing. However, because of the LUN reuse,<br>
the id may now be mapped to a different volume. Caller is asking me to<br>
disconnect volume with LUN5. From just looking at the device name<br>
there is no way of telling which openstack volume it is.<br>
<br>
/dev/disk/by-path/ip-172.30.128.3:3260-iscsi-iqn.1992-08.com.netapp:node.netapp02-lun-5<br>
-> ../../sdg<br>
<br>
How to get out of this .. ?<br>
<br>
1) Do not call 'disconnect_volume' for volumes that were successfully<br>
disconnected before. In other words, disconnect_volume is not<br>
idempotent anymore.<br>
<br>
2) Wipeout connection_info after disconnect. At least for Netapp<br>
provider it makes no sense to retain the info which is no longer valid<br>
anyway.<br>
<br>
3) do not reuse LUN ids - this would require major driver change to<br>
keep track of all currently used LUNs for both attached and detached<br>
volumes<br>
<br>
4) store "somewhere" on the host system mapping between LUNs and<br>
openstack volumes. You could check against it, before disconnecting a<br>
LUN device<br>
<br>
None of the options is too pleasant. Any suggestions how to address<br>
the problem ?<br>
<br>
Regards,<br>
<br>
Brano Zarnovican<br>
<br>
PS: We are using Essex. LUN reusing is a feature of Netapp that exists<br>
in all versions of the driver (IMO). By a quick glance I think the<br>
same problem with disconnect_volume exists on Folsom and master<br>
branch.<br></blockquote><div><br></div><div style>I'm using Folsom with a NetApp appliance and can confirm the problem exists.</div></div><br><br clear="all"><div><br></div>-- <br>Joe Topjian<div>Systems Administrator</div>
<div>Cybera Inc.</div><div><br></div><div><a href="http://www.cybera.ca" target="_blank">www.cybera.ca</a></div><div><br></div><div><font color="#666666"><span>Cybera</span><span> is a not-for-profit organization that works to spur and support innovation, for the economic benefit of Alberta, through the use of cyberinfrastructure.</span></font></div>

</div></div>