NetApp ontap driver fails to clone file from glance and cinder image cache

[Lars]

The netapp ontap cinder drivers always clones images from the glance store, or cached images (both on the same flexvol) with the function _clone_file_dst_exists. The problem here is that the argument dest_exists always is set to True without any check if the destination file already exists. If dest_exists set True there is added a xml child tag <destination-exists>True</destination-exists>. In my opinion this should all work well, but the netapp storage throws an error if destination-exists is set True (or CLI option -overwrite-destination) and the destination file does not exist. For more details about the netapp issue see: https://community.netapp.com/t5/OpenStack-Discussions/Clone-file-does-not-exist-error-occurs-when-creating-volume/m-p/144115/highlight/true#M370

There are two possible solutions:
1. Don't set dest_exists always to True. In my opinion there shouldn't already be a file with the same name, because a new volume always gets a new unique ID and if the destination file already exists netapp throws an error and the sys-admin should check it manually.
2. Implement a function to check if the file already exists, don't set it to True by default and move the function _clone_file_dst_exists to _clone_file_dst and let this function check if the destination file exists or not.

[Balasubramanian Ramesh Babu (balaramesh)]

Can you share some details about your environment? (Version of ONTAP, OpenStack)?

[Lars (l4rs)]

Yes, sure.

Cinder:
ii cinder-api 2:13.0.0-0ubuntu3~cloud0 all Cinder storage service - API server
ii cinder-common 2:13.0.0-0ubuntu3~cloud0 all Cinder storage service - common files
ii cinder-scheduler 2:13.0.0-0ubuntu3~cloud0 all Cinder storage service - Scheduler server
ii cinder-volume 2:13.0.0-0ubuntu3~cloud0 all Cinder storage service - Volume server
ii python-cinder 2:13.0.0-0ubuntu3~cloud0 all Cinder Python 2 libraries
ii python-cinderclient 1:3.5.0-0ubuntu1 all Python bindings to the OpenStack Volume API - Python 2.x

NetApp:
mynetapp::> version
NetApp Release 8.3.2P6: Mon Sep 12 12:29:03 UTC 2016

Do you need any further information?

[Balasubramanian Ramesh Babu (balaramesh)]

Hi Lars, the issue is with the version of ONTAP. This has been resolved in ONTAP 9.x, so if you upgrade ONTAP to any 9.x version, you will not be seeing this.

[Lars (l4rs)]

Hi, thank you for clarification. We will update our netapp storage and this bug can be closed.

[Lars (l4rs)]

Hi Balasubramanian, where did you find that information, that this bug has been fixed in 9.2? We are looking for a minor update to fix this, because at the moment we are unable to update our netapp to 9.2. Thank you.

[Balasubramanian Ramesh Babu (balaramesh)]

I am not sure if there is any documentation that reflects this, but I have tried it on 9.1, 9.2 and 9.3 and do not observe this issue.