manila/releasenotes/notes/bug-1848608-1893718-fix-manage-api-for-shares-with-multiple-export-locations-32ade25e9d82535b.yaml
haixin 1b5771ef15 Fix logic that determines a share exists before manage
The share "manage" API checks whether
an existing/known share is being imported by
matching the export path provided to existing
shares.

This lookup does not consider the
fact that shares may have multiple export
locations, because it relies on an old/deprecated
"export_location" property on shares which
was added to provide backwards compatibility
to the API that presented only one export
location per share.

Further, it's possible to get a
"ERROR: Invalid share: Share already exists"
exception even when no such share exists in the
database.

Fix the lookup by using the "export_location_path"
based lookup which is faster, since it performs
a meaningful join on the export locations table;
and remove the parameters "protocol"
and "share_type_id" - these things make no
difference when there's a duplicated export
location. We'll consider "host" as a lookup
parameter since we can't be sure that export
locations are unique in a deployment - but they
ought to be unique for a given host.

Closes-Bug: #1848608
Closes-Bug: #1893718
Change-Id: I1d1aef0c2b48764789b43b91b258def6464b389f
Co-Authored-By: Goutham Pacha Ravi <gouthampravi@gmail.com>
Signed-off-by: Goutham Pacha Ravi <gouthampravi@gmail.com>
2020-10-19 15:25:07 +08:00

12 lines
552 B
YAML

---
fixes:
- |
The `API to import shares into manila
<https://docs.openstack.org/api-ref/shared-file-system/#manage-share-since-api-v2-7>`_
could sometimes allow a share to be "managed" into manila multiple times
via different export paths. This API could also incorrectly
disallow a manage operation citing a new share in question was already
managed. Both issues have now been fixed. See `bug
#1848608 <https://launchpad.net/bugs/1848608>`_ and `bug #1893718
<https://launchpad.net/bugs/1893718>`_ for more details.