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:
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
HEAD is now at 53c0e27... Fix share can not be found by name in admin context
You can no longer show the details of the share by name:
stack@scspa0341462001:~/python-manilaclient$ manila show testadmindemoshare1
ERROR: Multiple share matches found for 'testadmindemoshare1', use an ID to be more specific.
Within a project, you can control manually that no two shares can have overlapping names, however, across projects, name collisions are certainly more probable and cannot usually be controlled.
That said, we might be able to live with this behavior in the interest of being consistent with other openstack clients (cinder), since the administrator may be able to workaround the collisions by:
$ manila list --name share-that-i-am-looking-for
(Grab the ID of the share you're looking for)
$ manila show <ID>
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: update" commands to respond slower for having to process all that extra data.
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/
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 (e1afea08080f48 34b9d9dbe3fdb41 2c2)
stack@scspa0341 462001: ~/python- manilaclient$ manila list --all-tenants ------- ------- ------- ------- ----+-- ------- ------- ------+ ------+ ------- ------+ ------- ----+-- ------- --+---- ------- ------+ ------- ------- ------- ------- ------- ----+-- ------- ------- ---+--- ------- ------- ------- ------- ---+ ------- ------- ------- ------- ----+-- ------- ------- ------+ ------+ ------- ------+ ------- ----+-- ------- --+---- ------- ------+ ------- ------- ------- ------- ------- ----+-- ------- ------- ---+--- ------- ------- ------- ------- ---+ 8d03-4930- 8ad5-9c414be30a 9e | testadminshare1 | 1 | NFS | available | False | dhss_false | scspa0341462001 @cmodeSSVMNFS_ 01#aggr1 | nova | f2e7e6e3a3af4e3 f8a66e78b0bfa84 3e | e1cd-400e- aa6f-7619a4cee1 c2 | testadmindemoshare1 | 1 | NFS | available | False | dhss_false | scspa0341462001 @cmodeSSVMNFS_ 01#aggr1 | nova | e1afea08080f483 4b9d9dbe3fdb412 c2 | 767f-4b6a- 9aca-56666a1e4c 2b | testadminadmins hare1 | 1 | NFS | available | False | dhss_false | scspa0341462001 @cmodeSSVMNFS_ 01#aggr1 | nova | e1afea08080f483 4b9d9dbe3fdb412 c2 | fba9-46e0- ab1f-fcd974f172 4a | testadmindemoshare1 | 1 | NFS | available | False | dhss_false | scspa0341462001 @cmodeSSVMNFS_ 01#aggr1 | nova | f2e7e6e3a3af4e3 f8a66e78b0bfa84 3e | ------- ------- ------- ------- ----+-- ------- ------- ------+ ------+ ------- ------+ ------- ----+-- ------- --+---- ------- ------+ ------- ------- ------- ------- ------- ----+-- ------- ------- ---+--- ------- ------- ------- ------- ---+
+------
| ID | Name | Size | Share Proto | Status | Is Public | Share Type Name | Host | Availability Zone | Project ID |
+------
| 054ba02a-
| 9a58f6f1-
| cb3f200d-
| f83c76b8-
+------
Today, the behavior is to only sift through the admin project shares to find the share by name:
stack@scspa0341 462001: ~/python- manilaclient$ manila show testadmindemoshare1 ------- ------- ------- ------- -----+- ------- ------- ------- ------- ------- ------- ------- ------- ------- ---+ ------- ------- ------- ------- -----+- ------- ------- ------- ------- ------- ------- ------- ------- ------- ---+ 117.153: /share_ a67899f9_ 313c_4076_ acba_84a1658c38 62 | b45f-4232- 9589-1da9cc8c41 f0 | 313c-4076- acba-84a1658c38 62 | @cmodeSSVMNFS_ 01#aggr1 | to_snapshot_ support | False | share_from_ snapshot_ support | False | e1cd-400e- aa6f-7619a4cee1 c2 | share_group_ snapshot_ member_ id | None | 1814e3330d04667 a7 | f6a6-42dd- 9aca-e670993e6b ee | 07T19:03: 17.000000 | support | False | 4b9d9dbe3fdb412 c2 | ------- ------- ------- ------- -----+- ------- ------- ------- ------- ------- ------- ------- ------- ------- ---+
+------
| Property | Value |
+------
| status | available |
| share_type_name | dhss_false |
| description | None |
| availability_zone | nova |
| share_network_id | None |
| export_locations | |
| | path = 10.250.
| | preferred = True |
| | is_admin_only = False |
| | id = 12054386-
| | share_instance_id = a67899f9-
| share_server_id | None |
| share_group_id | None |
| host | scspa0341462001
| revert_
| access_rules_status | active |
| snapshot_id | None |
| create_
| is_public | False |
| task_state | None |
| snapshot_support | False |
| id | 9a58f6f1-
| size | 1 |
| source_
| user_id | 153b4a22921b410
| name | testadmindemoshare1 |
| share_type | 596292e2-
| has_replicas | False |
| replication_type | None |
| created_at | 2017-12-
| share_proto | NFS |
| mount_snapshot_
| project_id | e1afea08080f483
| metadata | {} |
+------
With the code change: ------- -------
-------
stack@scspa0341 462001: ~/python- manilaclient$ git fetch https:/ /git.openstack. org/openstack/ python- manilaclient refs/changes/ 52/522452/ 2 && git checkout FETCH_HEAD /git.openstack. org/openstack/ python- manilaclient 52/522452/ 2 -> FETCH_HEAD
remote: Counting objects: 17, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 9 (delta 8), reused 2 (delta 1)
Unpacking objects: 100% (9/9), done.
From https:/
* branch refs/changes/
Note: checking out 'FETCH_HEAD'.
You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:
git checkout -b <new-branch-name>
HEAD is now at 53c0e27... Fix share can not be found by name in admin context
You can no longer show the details of the share by name:
stack@scspa0341 462001: ~/python- manilaclient$ manila show testadmindemoshare1 hare1', use an ID to be more specific.
ERROR: Multiple share matches found for 'testadmindemos
Within a project, you can control manually that no two shares can have overlapping names, however, across projects, name collisions are certainly more probable and cannot usually be controlled.
That said, we might be able to live with this behavior in the interest of being consistent with other openstack clients (cinder), since the administrator may be able to workaround the collisions by:
$ manila list --name share-that- i-am-looking- for
(Grab the ID of the share you're looking for)
$ manila show <ID>