[Bug 2015881] [NEW] Two API round trips just to show user by name (osc_lib find_resource method)

[Christian Rohmann]

Public bug reported:

I noticed quite a few errors about non existing users (and other
resources) in the logs and dug a little deeper.

When issuing a "show user" via: "openstack user show myuser",
so using the user's name, there are two API calls:

```
Output (/var/log/apache2/keystone_wsgi_access.log)
127.0.0.1 - - [28/Mar/2023:12:52:02 +0000] "GET /v3/users/myuser HTTP/1.1" 404 84 "-" "python-keystoneclient"
127.0.0.1 - - [28/Mar/2023:12:52:03 +0000] "GET /v3/users?name=myuser HTTP/1.1" 200 331 "-" "python-keystoneclient"
```

compared to when using the id via: openstack user show
295ddc1534a9422792d6896f6f7f223e


```
Output (/var/log/apache2/keystone_wsgi_access.log)
GET /v3/users/295ddc1534a9422792d6896f6f7f223e HTTP/1.1" 200 299 "-" "python-keystoneclient"
```


Apparently it's the find_resource helper method from osc_lib (https://github.com/openstack/osc-lib/blob/db9cdc95ed96045ff47c02cf822b1ba90ffa67b0/osc_lib/utils/__init__.py#L168) that is at e.g. https://github.com/openstack/python-openstackclient/blob/864f51f427c01d13c8408782dd03be4b473f7b2e/openstackclient/identity/v3/user.py#L602 that does apply this strategy.


Is there really no way to determine if the string received from the command line is an ID or some other string (~ a name) and then do "the right" call to save a round trip?


Likely this issue applies to other resources as well as find_resource is
also used elsewhere.

** Affects: python-openstackclient (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to python-openstackclient in Ubuntu.
https://bugs.launchpad.net/bugs/2015881

Title:
  Two API round trips just to show user by name (osc_lib find_resource
  method)

Status in python-openstackclient package in Ubuntu:
  New

Bug description:
  I noticed quite a few errors about non existing users (and other
  resources) in the logs and dug a little deeper.

  When issuing a "show user" via: "openstack user show myuser",
  so using the user's name, there are two API calls:

  ```
  Output (/var/log/apache2/keystone_wsgi_access.log)
  127.0.0.1 - - [28/Mar/2023:12:52:02 +0000] "GET /v3/users/myuser HTTP/1.1" 404 84 "-" "python-keystoneclient"
  127.0.0.1 - - [28/Mar/2023:12:52:03 +0000] "GET /v3/users?name=myuser HTTP/1.1" 200 331 "-" "python-keystoneclient"
  ```

  compared to when using the id via: openstack user show
  295ddc1534a9422792d6896f6f7f223e

  
  ```
  Output (/var/log/apache2/keystone_wsgi_access.log)
  GET /v3/users/295ddc1534a9422792d6896f6f7f223e HTTP/1.1" 200 299 "-" "python-keystoneclient"
  ```

  
  Apparently it's the find_resource helper method from osc_lib (https://github.com/openstack/osc-lib/blob/db9cdc95ed96045ff47c02cf822b1ba90ffa67b0/osc_lib/utils/__init__.py#L168) that is at e.g. https://github.com/openstack/python-openstackclient/blob/864f51f427c01d13c8408782dd03be4b473f7b2e/openstackclient/identity/v3/user.py#L602 that does apply this strategy.

  
  Is there really no way to determine if the string received from the command line is an ID or some other string (~ a name) and then do "the right" call to save a round trip?


  Likely this issue applies to other resources as well as find_resource
  is also used elsewhere.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-openstackclient/+bug/2015881/+subscriptions