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

[Christian Rohmann]

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.

[Corey Bryant (corey.bryant)]

I'll add upstream openstackclient since this doesn't appear to be a package specific bug for Ubuntu.

[Artem Goncharov (gtema)]

No, there is no reliable way of doing that. It is an issue related to every resource and not only user

[Christian Rohmann (christian-rohmann)]

May one could see if the format of the input looks like a UUID and then test that first, otherwise check for name first?
This would, in most cases, straight out half the number of API requests and latency for all of those requests.

[Artem Goncharov (gtema)]

this is a very very error prone approach. What if somebody gives name that are UUID like? There is nothing preventing that. Looking at "look like" is proven to be just wrong. In addition to that as far as I remember there are certain services where IDs are not UUID like - once we have seen that we stopped even further thinking about that.

[Christian Rohmann (christian-rohmann)]

1) I am not saying make this a strict if / else, but rather start in the right order of going through the cases in https://github.com/openstack/osc-lib/blob/db9cdc95ed96045ff47c02cf822b1ba90ffa67b0/osc_lib/utils/__init__.py#L168.

This would not make it any worse (apart from more code), but potentially half the number of expensive API calls. The whole "find_resource" method works on a best-effort basis anyways, by not make this effort a little better :-)

2) The same issue / bug of doing two round trips in case a name is used applies to the OpenSDK at https://github.com/openstack/openstacksdk/blob/7235634f74c595610c912f332be03523b956933b/openstack/resource.py#L2252 right? There the string is first tried to used as ID and then as the name of the resource.

3) I am really discouraged by the "nothing can be done" thing you said about this issue. Yes, not having a common ID format across all resources is unlikely to be fixed (ever). But why not discuss the introduction of explicit and mutually exclusive "--id" "--name" parameters (and matching find_by_id and find_by_name functions in the OpenStackSDK) to then only ask for name or id and definitely only do one round of API roller coaster. The current "find" method could remain the default. But in case someone knows if an ID or name is used (e.g. when using the openstackclient via the proposed "--id" parameter).

Edit: While I re-read this ... regarding 3) it would likely only require "--name", as the "find" method already tries the ID first.

[Artem Goncharov (gtema)]

but the 3) would require UX change pretty much everywhere and that is not going to be a cheap/easy change
"user show <IDENTIFICATOR>" => "user show [--id <IDENTIFICATOR>|--name <IDENTIFICATOR>]" => "user set [--id <IDENTIFICATOR>|--name <IDENTIFICATOR>]" .....

[Artem Goncharov (gtema)]

in the 1) you may end up in a situation, that you pass flavor/image/etc id, but the find anyway pulls 1000 flavors from the region (ignoring all possible server side filters) to filter on the client side through that

[Artem Goncharov (gtema)]

and wrt 2) - there are resource which do not have id at all (i.e. keypair)

Generally - we should improve API performance and not perform magic to skip one API call. Depending on the cloud it is 50-300 ms. There are clearly other things which waste much more time