NetApp cDOT backed cinder volume deletion can be slow

[Tom Barron]

Deletes of cinder volumes backed by NetApp cDOT flexvols can be slow.

NetApp cDOT driver creation of cinder volumes from glance images uses cloning technologies in the backend array to achieve almost instantaneous create operations. If the glance image and the cinder pool for the newly created volume are backed by the same "flexvol", this cloning optimization is always done. If not, then although a slow path for volume creation is taken the first time a cinder volume is created from a glance image, we cache a copy of the glance image on the destination flexvol, so that n+1 creates from the same image benefit from this fast array-side clone capability.

Sadly, customers have reported experiencing array-side performance issues when running batches of deletes in quick succession of these backing files, especially when they are large.

DOT 8.3 introduced a new file deletion engine for cloned files that addresses this large-cloned-file delete performance issue.

NetApp cDOT cinder drivers should use this new file deletion engine rather than simply relying on parent class delete volume and delete snapshot methods.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/225306

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/225306
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=4163fb29add1f3c80cb902c8735be3dde24930d3
Submitter: Jenkins
Branch: master

commit 4163fb29add1f3c80cb902c8735be3dde24930d3
Author: Tom Barron <email address hidden>
Date: Mon Sep 14 17:38:40 2015 -0400

    NetApp volume/snapshot delete performance fix

    cDOT NFS NetApp drivers back cinder volumes with array-side files and
    use array-side cloning techniques when creating snapshots and when
    creating volumes from glance images. Customers have experienced
    performance issues on the array when deleting many of these in
    in quick succession, especially for large volumes.

    This commit addresses these performance issues by overriding parent
    class volume and snapshot delete methods, which use OS "rm" command to
    delete volume backing files, with methods that use DOT API to delete
    these files, and which invoke the optimized file deletion engine
    available in DOT 8.3.

    Closes-bug: 1497258
    Change-Id: I44428d0840f6584f93ca214a2a607869b345554c

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/kilo
Review: https://review.openstack.org/232701

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/232701
Committed: https://git.openstack.org/cgit/openstack/cinder/commit/?id=7cce8719f23bd35c10144f8232c80e31ccef1019
Submitter: Jenkins
Branch: stable/kilo

commit 7cce8719f23bd35c10144f8232c80e31ccef1019
Author: Tom Barron <email address hidden>
Date: Mon Sep 14 17:38:40 2015 -0400

    NetApp volume/snapshot delete performance fix

    cDOT NFS NetApp drivers back cinder volumes with array-side files and
    use array-side cloning techniques when creating snapshots and when
    creating volumes from glance images. Customers have experienced
    performance issues on the array when deleting many of these in
    in quick succession, especially for large volumes.

    This commit addresses these performance issues by overriding parent
    class volume and snapshot delete methods, which use OS "rm" command to
    delete volume backing files, with methods that use DOT API to delete
    these files, and which invoke the optimized file deletion engine
    available in DOT 8.3.

    Note that some unit tests were not backported since they depended on
    modules not available in kilo.

    Closes-bug: 1497258
    (cherry picked from commit 4163fb29add1f3c80cb902c8735be3dde24930d3)

    Conflicts:
     cinder/tests/volume/drivers/netapp/dataontap/fakes.py

    Change-Id: I44428d0840f6584f93ca214a2a607869b345554c