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

[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.

-- 
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:
  Won't Fix
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/python-openstackclient/+bug/2015881/+subscriptions