Uploaded image for project: 'Red Hat OpenStack Services on OpenShift'
  1. Red Hat OpenStack Services on OpenShift
  2. OSPRH-20328

Manila NetApp driver fails to delete cloned shares

XMLWordPrintable

    • 5
    • False
    • Hide

      None

      Show
      None
    • False
    • ?
    • openstack-manila-16.3.0-18.0.20250926205153.3c01b71.el9ost
    • rhos-storage-manila
    • None
    • Hide
      .Improved clone deletion management

      Before this update, NetApp ONTAP storage systems on version 9.13.1 or later rejected clone deletion requests for FlexVol snapshots and FlexClones if they were still processing. With this update, the NetApp ONTAP driver in the Shared File Systems service (manila) manages clone splitting operations before share or snapshot deletion, preventing deletion failures. Users can now delete Shared File Systems service snapshots and shares created from snapshots any time after creation without encountering clone deletion failures.
      Show
      .Improved clone deletion management Before this update, NetApp ONTAP storage systems on version 9.13.1 or later rejected clone deletion requests for FlexVol snapshots and FlexClones if they were still processing. With this update, the NetApp ONTAP driver in the Shared File Systems service (manila) manages clone splitting operations before share or snapshot deletion, preventing deletion failures. Users can now delete Shared File Systems service snapshots and shares created from snapshots any time after creation without encountering clone deletion failures.
    • Bug Fix
    • Done
    • Pending Verification, OSPRH Manila Sprint 9
    • 2
    • Important

      To Reproduce Steps to reproduce the behavior:

      1. Create a share, and a snapshot of the share, and clone the snapshot into a new share
      2. Delete the new share
      3.  If you perform (2) fast enough, there's a clone split operation in progress in the driver, and the share deletion call fails.

      Expected behavior

      • Clone splits are good for performance on long living shares. However, if a newly cloned share needs to be deleted, a queued clone split operation shouldn't block the deletion

      Bug impact

      • Shares can be stuck in "error_deleting" status which prevents their deletion by a regular non-privileged user.

      Known workaround

      • OpenStack "administrator" users can reset the "status" of the share stuck in "error_deleting" and attempt deletion 
      • Users can wait a while and then delete a newly cloned share, however, it is hard to say how long it'll take to complete clone splits - clone split jobs are "queued" by ONTAP, and they are executed when the ONTAP cluster has low load.

      Additional context

              rhn-engineering-gpachara Goutham Pacha Ravi
              rhn-engineering-gpachara Goutham Pacha Ravi
              Vida Haririan
              rhos-storage-manila
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated:
                Resolved: