Shares cannot be found by name in admin context

Bug #1721787 reported by Arne Wiebalck on 2017-10-06
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Manila
Medium
jiaopengju
python-manilaclient
Medium
Tom Barron

Bug Description

In admin context, the manila client fails to find shares (outside the admin tenant)
when only the share name is passed. ID works fine. [1]

The reason is

https://github.com/openstack/manila/blob/master/manila/share/api.py#L1595

which requires 'all_tenants' to be True, which is not set in the request
as sent by the client and hence the search is confined to the admin tenant.

The above code stems from Cinder days, but in Cinder the corresponding request
works now as the client is setting all_tenants to 1 when making the request. [2]

[1]
$ manila show xyz
ERROR: No share with a name or ID of 'xyz' exists.
$
$ manila show e653ff96-0b23-4352-801d-4e7032f34db1|grep name
| name | xyz

[2]
$ manila --debug show xyz 2>&1|grep detail
...
REQ: curl -i -X GET https:.../v2/aaabbb/shares/detail?is_public=True ...
$
$ cinder --debug show vol-xyz 2>&1|grep detail
$REQ: curl -g -i -X GET https:.../v3/aaaabbb/volumes/detail?all_tenants=1&name=arnemaster2341 ...

summary: - Shares cannot be found in admin context
+ Shares cannot be found by name in admin context
Changed in manila:
status: New → Confirmed
Dustin Schoenbrun (dschoenb) wrote :

I just verified that this does indeed happen with the latest version of Devstack. My procedure was as follows using the Generic Share Driver:

source openrc
manila share-network-create --neutron-net-id <private_neutron_net_id> --neutron-subnet-id <private_neutron_subnet_id> share-net
manila create NFS 1 --name test --share-network share-net
source openrc admin admin
manila show test

The final command will fail with the error indicated above. Thanks for the report, Arne!

Changed in python-manilaclient:
status: New → Confirmed
description: updated
description: updated
Changed in manila:
importance: Undecided → Medium
Changed in python-manilaclient:
importance: Undecided → Medium
jiaopengju (pj-jiao) on 2017-11-20
Changed in manila:
assignee: nobody → jiaopengju (pj-jiao)
assignee: jiaopengju (pj-jiao) → nobody
assignee: nobody → jiaopengju (pj-jiao)
Changed in python-manilaclient:
assignee: nobody → jiaopengju (pj-jiao)

Fix proposed to branch: master
Review: https://review.openstack.org/522452

Changed in python-manilaclient:
status: Confirmed → In Progress

Fix proposed to branch: master
Review: https://review.openstack.org/522607

Changed in manila:
status: Confirmed → In Progress
Goutham Pacha Ravi (gouthamr) wrote :
Download full text (8.8 KiB)

I don't agree that this bug exists on Manila. This is a client issue. show/update/delete by name is a client side optimization for better user experience. The workaround workflow is:

$ manila list --all-tenants --name share-that-i-am-looking-for
(Grab the ID of the share you're looking for)
$ manila show <ID>

However, that said, we can implement jiaopengju's fix. There are a couple of downsides to this approach however:

1) Performance Impact:
show/delete/update by name is implemented as a "if not UUID, list all resources and sift through them to find the resource indicated by the name specified". So, listing all the resources belonging to all the tenants of a cloud may cause the "show/delete/update" commands to respond slower for having to process all that extra data.

2) More chances of collisions:

Here's the situation by example:
--------------------------------

There are 4 shares in this cloud, 2 of them named the same, however, only one of them belongs to the "admin" project (e1afea08080f4834b9d9dbe3fdb412c2)

stack@scspa0341462001:~/python-manilaclient$ manila list --all-tenants
+--------------------------------------+----------------------+------+-------------+-----------+-----------+-----------------+---------------------------------------+-------------------+----------------------------------+
| ID | Name | Size | Share Proto | Status | Is Public | Share Type Name | Host | Availability Zone | Project ID |
+--------------------------------------+----------------------+------+-------------+-----------+-----------+-----------------+---------------------------------------+-------------------+----------------------------------+
| 054ba02a-8d03-4930-8ad5-9c414be30a9e | testadminshare1 | 1 | NFS | available | False | dhss_false | scspa0341462001@cmodeSSVMNFS_01#aggr1 | nova | f2e7e6e3a3af4e3f8a66e78b0bfa843e |
| 9a58f6f1-e1cd-400e-aa6f-7619a4cee1c2 | testadmindemoshare1 | 1 | NFS | available | False | dhss_false | scspa0341462001@cmodeSSVMNFS_01#aggr1 | nova | e1afea08080f4834b9d9dbe3fdb412c2 |
| cb3f200d-767f-4b6a-9aca-56666a1e4c2b | testadminadminshare1 | 1 | NFS | available | False | dhss_false | scspa0341462001@cmodeSSVMNFS_01#aggr1 | nova | e1afea08080f4834b9d9dbe3fdb412c2 |
| f83c76b8-fba9-46e0-ab1f-fcd974f1724a | testadmindemoshare1 | 1 | NFS | available | False | dhss_false | scspa0341462001@cmodeSSVMNFS_01#aggr1 | nova | f2e7e6e3a3af4e3f8a66e78b0bfa843e |
+--------------------------------------+----------------------+------+-------------+-----------+-----------+-----------------+---------------------------------------+-------------------+----------------------------------+

Today, the behavior is to only sift through the admin project shares to find the share by name:

stack@scspa0341462001:~/python-manilaclient$ manila show testadmindemoshare1
+---------------------------------------+-------------------------------------------------------------------+
| Property ...

Read more...

Arne Wiebalck (arne-wiebalck) wrote :

Goutham, thanks for looking into this and for your comments!

Concerning performance: I'd think the time to run two commands (and copy the UUID in between)
will probably be longer than the increased runtime for sieving through all shares.
Also, I'd expect the number of shares in Manila to be small compared to the number of
volumes in Cinder (in our deployment the ratio is currently ~1:100), and Cinder finds
a volume by name in ~1 sec (sieving through our +5000 active volumes). So, I'd opt for
admin convenience (and consistency) here :)

As for collisions: as this whole issue is limited to admins, I think handling the
collisions is ok. As an admin looking through all projects you should not be surprised
to have several shares with the same name.

Anyway, all this is of course not a big problem. As you mentioned, the main thing may be
to establish consistency across projects.

Reviewed: https://review.openstack.org/522607
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=9f69258cab9baf77384282b67feb390d0487d3b9
Submitter: Zuul
Branch: master

commit 9f69258cab9baf77384282b67feb390d0487d3b9
Author: Jiao Pengju <email address hidden>
Date: Thu Nov 23 23:15:36 2017 +0800

    Fix getting share networks and security services error

    It will fail when non-admin tenants try to get share networks
    and security services with option '{all_tenants: 1}'.
    The reason is that the policy of 'get_all_share_networks' and
    'get_all_security_services' are admin api, they do not allow
    the non-admin tenants list the share networks and security
    services with all_tenants=1. This patch removes the policy check
    of non-admin tenants and allows non-admin tenants to request to
    list with 'all_tenants=1', however 'all_tenants' in the request
    is just ignored.

    Change-Id: Ied021b66333f1254cd232bbc38562a4a9b762ad2
    Co-Authored-By: Goutham Pacha Ravi <email address hidden>
    Related-Bug: #1721787

Changed in python-manilaclient:
assignee: jiaopengju (pj-jiao) → Tom Barron (tpb)

Reviewed: https://review.openstack.org/522452
Committed: https://git.openstack.org/cgit/openstack/python-manilaclient/commit/?id=b9ebff14caddf42b629ba00bc9ea52ac2b39117b
Submitter: Zuul
Branch: master

commit b9ebff14caddf42b629ba00bc9ea52ac2b39117b
Author: Jiao Pengju <email address hidden>
Date: Thu Nov 23 14:31:33 2017 +0800

    Fix share can not be found by name in admin context

    Currently, when using admin context to execute 'manila
    show <share-name>' to show a share detail which is not
    owned by admin, it always fails with 'No share with a
    name or ID of <share-name> exists'. This patch will fix
    it.

    Change-Id: I96339778fa69c379863078250d5dfa7172f2c1b2
    Closes-Bug: #1721787

Changed in python-manilaclient:
status: In Progress → Fix Released

Reviewed: https://review.openstack.org/529134
Committed: https://git.openstack.org/cgit/openstack/python-manilaclient/commit/?id=e657bfe743c04f26c9b1003c8c8e598c829f03a8
Submitter: Zuul
Branch: stable/pike

commit e657bfe743c04f26c9b1003c8c8e598c829f03a8
Author: Jiao Pengju <email address hidden>
Date: Thu Nov 23 14:31:33 2017 +0800

    Fix share can not be found by name in admin context

    Currently, when using admin context to execute 'manila
    show <share-name>' to show a share detail which is not
    owned by admin, it always fails with 'No share with a
    name or ID of <share-name> exists'. This patch will fix
    it.

    Change-Id: I96339778fa69c379863078250d5dfa7172f2c1b2
    Closes-Bug: #1721787
    (cherry picked from commit b9ebff14caddf42b629ba00bc9ea52ac2b39117b)

tags: added: in-stable-pike

This issue was fixed in the openstack/python-manilaclient 1.20.0 release.

Reviewed: https://review.openstack.org/528731
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=7a6955dd7fa47b51e5f2a7766061066ffaa0af8d
Submitter: Zuul
Branch: stable/pike

commit 7a6955dd7fa47b51e5f2a7766061066ffaa0af8d
Author: Jiao Pengju <email address hidden>
Date: Thu Nov 23 23:15:36 2017 +0800

    Fix getting share networks and security services error

    It will fail when non-admin tenants try to get share networks
    and security services with option '{all_tenants: 1}'.
    The reason is that the policy of 'get_all_share_networks' and
    'get_all_security_services' are admin api, they do not allow
    the non-admin tenants list the share networks and security
    services with all_tenants=1. This patch removes the policy check
    of non-admin tenants and allows non-admin tenants to request to
    list with 'all_tenants=1', however 'all_tenants' in the request
    is just ignored.

    Change-Id: Ied021b66333f1254cd232bbc38562a4a9b762ad2
    Co-Authored-By: Goutham Pacha Ravi <email address hidden>
    Related-Bug: #1721787
    (cherry picked from commit 9f69258cab9baf77384282b67feb390d0487d3b9)

jiaopengju (pj-jiao) on 2018-01-25
Changed in manila:
status: In Progress → Fix Released

This issue was fixed in the openstack/python-manilaclient 1.17.3 release.

Reviewed: https://review.openstack.org/587684
Committed: https://git.openstack.org/cgit/openstack/manila/commit/?id=95aea67f919042fba97d735c4294afed4722f7e6
Submitter: Zuul
Branch: stable/ocata

commit 95aea67f919042fba97d735c4294afed4722f7e6
Author: Jiao Pengju <email address hidden>
Date: Thu Nov 23 23:15:36 2017 +0800

    Fix getting share networks and security services error

    It will fail when non-admin tenants try to get share networks
    and security services with option '{all_tenants: 1}'.
    The reason is that the policy of 'get_all_share_networks' and
    'get_all_security_services' are admin api, they do not allow
    the non-admin tenants list the share networks and security
    services with all_tenants=1. This patch removes the policy check
    of non-admin tenants and allows non-admin tenants to request to
    list with 'all_tenants=1', however 'all_tenants' in the request
    is just ignored.

    Change-Id: Ied021b66333f1254cd232bbc38562a4a9b762ad2
    Co-Authored-By: Goutham Pacha Ravi <email address hidden>
    Related-Bug: #1721787
    (cherry picked from commit 9f69258cab9baf77384282b67feb390d0487d3b9)
    (cherry picked from commit 7a6955dd7fa47b51e5f2a7766061066ffaa0af8d)

tags: added: in-stable-ocata
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers