NetApp delete volume with ongoing clone split

Bug #1960239 reported by Maurice Escher
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Shared File Systems Service (Manila)
In Progress
Felipe Rodrigues

Bug Description


shares that were created from snapshot and are deleted after a short lifetime end up in error_deleting. Now I have to come back later, reset state and try to delete again.
In the logs I see "Failed to unmount volume [...] after waiting for 30 seconds."

My expectation would be: deleting a share from snapshot works without waiting + retry.

I have Manila Xena with ONTAP 9.8 back end and set netapp:split_clone_on_create to "True".

Previously there may have been no way in figuring out that a clone split operation was ongoing (see but now in more recent ONTAP versions there is a 'volume-clone-split-status' command.

I suggest to improve the user experience: instead of waiting a few seconds for the job to finish (which may not be enough), stop the clone split in case of a unmount with force flag.

What do you think?


Tags: netapp
tags: added: netapp
Changed in manila:
assignee: nobody → Fernando Ferraz (fernando-ferraz)
Vida Haririan (vhariria)
Changed in manila:
importance: Undecided → Medium
Changed in manila:
milestone: none → zed-1
Changed in manila:
milestone: zed-1 → zed-2
Revision history for this message
Maurice Escher (maurice-escher) wrote :

Another idea would be to re-use the concept of soft-deleting from 'soft_delete_snapshot':
in case of an error on share delete, rename the share and try to delete later.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to manila (master)

Fix proposed to branch: master

Changed in manila:
status: New → In Progress
Changed in manila:
milestone: zed-2 → zed-3
Changed in manila:
assignee: Fernando Ferraz (fernando-ferraz) → Felipe Rodrigues (felipefutty)
Changed in manila:
milestone: zed-3 → antelope-1
Changed in manila:
milestone: antelope-1 → antelope-2
Changed in manila:
milestone: antelope-2 → antelope-3
Changed in manila:
milestone: antelope-3 → antelope-rc1
Changed in manila:
milestone: antelope-rc1 → bobcat-1
Changed in manila:
milestone: bobcat-1 → bobcat-2
Revision history for this message
Maurice Escher (maurice-escher) wrote :

Please see, deferred deletion may not be so easy to implement, since even rename could not be possible on a busy volume (just an assumption from a similar behaviour on snapshots)

Revision history for this message
kiran pawar (kpdev) wrote :
Changed in manila:
milestone: bobcat-2 → bobcat-3
Changed in manila:
milestone: bobcat-3 → caracal-1
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.