fix: inconsistent driver-updatable metadata delete

[skook1]

Fix inconsistent driver-updatable metadata delete

Deleting a share metadata key listed in driver_updatable_metadata now creates an UPDATE_METADATA_NOT_DELETED user message, matching the existing behavior for driver_updatable_subnet_metadata on share network subnets. Operators get consistent feedback that the deletion was not passed to the share driver.

Closes-Bug: #2156333
Change-Id: I315a8e55c169e030ee6eb290506e6450a02dffd1

[kpawar-sap]

what was the testing during which you observed this as a bug ?

[Carthaca]

The {key: None} breaks the NetApp driver's methods, that expect strings

Please add explicit handling when those receive None now:

update_volume_snapshot_policy()
update_cross_volume_dedupe()
update_showmount()
update_pnfs().

Extended scope, but would be nice:
if update_all_metadata deletes driver_updatable_metadata keys, the same logic (with {key: None}) should be applied to those keys
I'll leave it up to you, if you would want to include this here or in a follow-up.

[Carthaca]

This is for https://bugs.launchpad.net/manila/+bug/2156333

[Carthaca]

I only saw now, that this is proposed upstream, too - I copied my remarks to gerrit https://review.opendev.org/c/openstack/manila/+/1000846 Let's solve it upstream first, please ;)

[kpawar-sap]

IMHO, If user want to revert the behaviour they should use update metadata with new value rather than delete_metadata. Delete_metadata does not mean reset to default, as different driver can have different behaviour.

[Carthaca]

IMHO, If user want to revert the behaviour they should use update metadata with new value rather than delete_metadata. Delete_metadata does not mean reset to default, as different driver can have different behaviour.

but this is confusing to me:
If I have a share created without metadata it should be the same to a share that was created with metadata and the metadata got deleted later. I have no easy way (even audit logs will eventually expire) by looking at the share to know, if it had metadata earlier during it's lifetime to explain differing behaviour.

The other way I see would be to have all options that can be configured with metadata explicitly set and disallow to delete those keys, only allow updating the value. This would mean a plus in transparency, but on the downside we would blow up all shares with metadata.

[kpawar-sap]

If I have a share created without metadata it should be the same to a share that was created with metadata and the metadata got deleted later.
+1. This is better than disallowing deletion. I am ok with maintaining it consistent with share deletion.