-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deleting iSCSI volumes using Openstack Driver fails if one or more Truenas initiated snapshots exist #24
Comments
Yes, sadly this is a current limitation. The workaround, as you suggested, is to let OpenStack maintain the snapshots and then it can give a reasonable error message to the user, but even in that case a volume cannot be deleted when there are active snapshots for it. The snapshots still have to be deleted first. |
Thanks for the reply. |
Hi Beholder101, thank you for reporting this issue, this issue has been fixed by PR #33 merged to master branch, now the when you delete volume with snapshot or has clone dependence, the delete action simply return without stuck into error status. Also you mentioned deleting multiple volume only one volume get deleted, now all volumes get deleted in batch. If you see any further issues, appreciate your feedbacks! |
Openstack Ussuri and Truenas 11.3-U5
Scenario: If you create an iSCSI volume in Openstack using the iXSystems Cinder drivers, the volume gets created as expected. If you want to delete that volume at some point, it will fail if you have snapshots in Truenas that still contains a reference/copy/snap to the ZVOL that was created for this iSCSI endpoint. The disk in Openstack will proceed into an ERROR state, unable to delete it. Only if and after you have deleted all snapshots that contain the ZVOL reference on the Truenas, will you be able to recover from the disk deletion failure (change disk state - logged in as an admin - to 'Available') and redo the deletion. It will now finish the deletion successfully.
I have yet to try how this works out if Openstack is the one maintaining the snapshots.
Snapshots no longer seem a way to recover from a deleted disk when using iSCSI based Cinder volumes.
Expected behavior: at least a warning or message stating that deletion is not possible due to snapshots being present, although error reporting in Openstack is not mature (yet). A more preferred behavior would be that the deletion would complete successfully and keeping the snapshots for recovery later on, in case a user made a mistake. But my knowledge is limited as to the implications of each behavior.
The text was updated successfully, but these errors were encountered: