Description of problem:

manila's Manage API [1] does not prevent re-managing an already managed share under certain circumstances. The API performs a check by comparing the export location provided against all known shares in the manila database. However, that check does not work currently when a share has multiple export locations.

The retrieval logic for search options looks suspicious:

https://opendev.org/openstack/manila/src/commit/b6b2eb5cf3a32e506af8734acecb4a34ceafc982/manila/share/api.py#L1709-L1718

There's an attempt to retrieve the export location with the key "export_location" on the Share model (https://opendev.org/openstack/manila/src/commit/b6b2eb5cf3a32e506af8734acecb4a34ceafc982/manila/share/api.py#L671), but in reality, there is no such key on the database schema.

There's a meta property on the share model, which just fetches a share's instance's first export location:

- https://opendev.org/openstack/manila/src/commit/b6b2eb5cf3a32e506af8734acecb4a34ceafc982/manila/db/sqlalchemy/models.py#L206-L208

- https://opendev.org/openstack/manila/src/commit/b6b2eb5cf3a32e506af8734acecb4a34ceafc982/manila/db/sqlalchemy/models.py#L353-L355


Version-Release number of selected component (if applicable): 13 - 16+


How reproducible: Sporadically


Steps to Reproduce:
1. Configure manila with a backend that can present multiple export paths - for example, a NetApp vServer that can expose two or more NICs
2. Create a share, note its export locations
3. Use the manage API with the export locations, one at a time

Actual results:
Step 3 sometimes passes, resulting in a share getting managed twice - this could be disruptive to existing clients, and in some cases disastrous, because it requires some special handling for doubly managed shares to remove the duplicates, without causing data loss.

Expected results:
Step 3 must be disallowed always



Additional info:


[1] https://docs.openstack.org/api-ref/shared-file-system/#manage-share-since-api-v2-7