NetApp driver cannot delete share that has a deleted managed snapshot

[Felipe Rodrigues]

Description
===========
The NetApp driver is failing while delete a share that has a deleted managed snapshot. The deleted managed snapshot must be used to create a share from it, before deleting it. And, it must be used to revert.

The problem comes from the fact that the NetApp driver manages snapshot by renaming it. When reverting to that snapshot, the name comes back to previous name (the name when the snapshot was taken), making the manila loses the snapshot location.

Therefore, when the delete snapshot operation is called, the driver thinks that the managed snapshot is already delelted (cannot locate from new name). It will end up returning sucess, without deleting the snapshot.

Steps to reproduce
==================

A chronological list of steps which will help reproduce the issue you hit:

1) create a share using manila called s1

2) Go to ontap and create a snap with name not_managed_snap for that manila volume

3) Manage the snapshot not_managed_snap

4) Create a volume with name s2 from the snapshot not_managed_snap (it must be in the same pool)

5) Revert to not_managed_snap (the snapshot name is changed in the storage)

6) Delete the managed snapshot (it will answer with success, but the snapshot is still on ontap with different name)

7) Delete the first volume s1.. It will fail [1]: cannot delete a share (s1) that has snapshot (not_managed_snap) with relation with other volumes (s2)

- List of manila/openstack client commands: http://paste.openstack.org/show/807404/

Expected result
===============
Delete share that has a deleted managed snapshot

Actual result
=============
Error deleting the share

Environment
===========
1. OpenStack Wallaby (reproducible in latest version as well)

2. NetApp ONTAP 9.x

Logs & Configs
==============
[1] http://paste.openstack.org/show/807405/

[Felipe Rodrigues (felipefutty)]

Another side effect of the same issue: a snapshot can be deleted on manila without deleting on storage.

1. managing a snapshot
2. reverting the volume to the managed snapshot
3. delete the managed snapshot

The manila will succeed, but the snapshot will be still on storage. The reason is because during revert phase the name changed to the old name (before managing), so the delete thinks that it worked because no snapshot was found.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/manila/+/857627

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/manila/+/857627
Committed: https://opendev.org/openstack/manila/commit/1dc445945670ac510c845f248f7b58ff96c25021
Submitter: "Zuul (22348)"
Branch: master

commit 1dc445945670ac510c845f248f7b58ff96c25021
Author: Felipe Rodrigues <email address hidden>
Date: Wed Sep 14 22:27:56 2022 -0300

    [NetApp]: Fix issues with managed snapshot

    Managed snapshot has its name changed. When the volume is reverted
    to the snapshot, the name is reverted to the old too. As result,
    the Manila loses the snapshot reference, causing some issues.

    This patch is removing the code that renames the snapshot during
    management, so the snapshot name is kept as informed, saving it
    to the provider location field.

    Closes-bug: #1936648
    Change-Id: Ib1a928d453de80d6841524cdb86c4708a5b0dbdf

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/manila 16.0.0.0rc1 release candidate.