NetApp: available snapshot physically not created

[Maurice Escher]

Hi,

I have got snapshots in available state in my manila installation, where the snapshot is physically not existing on the NetApp backend according to the provider location.

So from frontend/manila perspective we have a working snapshot, but once we try to use it we notice it is broken or rather my customer reported that a share-revert-to-snapshot failed with "entry doesn't exist".

I found some more examples: 18 missing snapshots out of a total of 1542, so about 1 percent.
I'm still a bit puzzled how it could happen, most of the occurrences where on systems with very high load.

I think the NetApp driver should double check after sending snapshot-create that the snapshot has been properly created.

I will try to work on this improvement myself.

BR,
Maurice

[Maurice Escher (maurice-escher)]

Maybe to add some more about my investigations:
I'm running xena with DHSS=true

I know that the snapshot transitioned into available state seconds after it has been created (so it was no reset-state or any later change in the database). And it has not been involved in a replication scenario.

Some older (2 years old, 5 out of the mentioned 18 from above) snapshots did not even have a provider_location set.

[OpenStack Infra (hudson-openstack)]

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

[OpenStack Infra (hudson-openstack)]

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

commit f95cb40ee3a39872e71adaeeda1643f8b46694dc
Author: Maurice Escher <email address hidden>
Date: Thu May 5 16:01:59 2022 +0200

    [NetApp] check snapshot presence after creation

    Introduce some extra safety by an additional guard.
    Losing a snapshot is never an option, this justifies an
    additional api call to the NetApp storage back end.

    Change-Id: Ibc21b6c72d76a3a804f67e66e7604b3d0be4373f
    Related-Bug: #1971710

[Carlos Eduardo (silvacarlose)]

Maurice, could you please confirm if we can close this bug or if there are still actions to be taken or fixes to be proposed?