1b5771ef15
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>
12 lines
552 B
YAML
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.
|