I have observed that the keystone logs are flooded with error messages and a stack trace that resources are not found.
When investigating on the issue I noticed that the resources do exist but the behavior of the openstack-client is a bit confusing.
I will describe the behavior for the openstack-client in the interaction with the kestone api.
As know the openstack-cli which uses the openstack-client has the functionality to show a user either by passing an id or the
name of the user. The requests when executing the command with the name of the user will be
1. v3/user/<name_or_id>
- v3/user?name=<name_or_id>
The first request is issued to the endpoint which expects the rout parameter to be an id of the user and in the case of the
keystone api a db query is executed with the name as an id and no user will be found which results in the log message and
the stack trace in the keyston logs. Because no user was found the openstack-client issues a second request to the api
with the name as a query-parameter instead of a rout-parameter which will issue the db-query at the keystone api to search
by the username. On some deployments this can and will be additional load on the database and on the api which can be
reduced just by sending the correct request to the api instead of "guessing" and trying for the correct request and hoping
there will be an answer.
The issue with keystone is that the openstack-client will issue also requests to the keystone api when listing, e.g. networks
but only for a specific project (openstack network list --project <name_or_id>). The client will first search for the project and
in the worst case these are two requests.
In my opinion this behavior can be prevented to send multiple requests to the keystone api (or any other api), either by
checking on the client if a the passed parameter is an id or by handling the passed route-parameter accordingly in the keystone
api and executing the correct db-query to prevent multiple requests.
I have decided on implementing a change [1] on the client side and have adjusted the openstack-client.
As artem pointed out in the review that in some services there are places where the id cannot be really identified as such
I wanted to ask/I was asked to discuss the issue on the mailing list since there might be multiple projects involved in such
a change to reduce the calls to the api (when handling on the client side) or db (when handling on the server side) when
a search by an id or name is issued.
Are there an plans on tackling this issue or any other options and opinions?
The post by marc [2] might also be a result of the openstack-client issuing multiple requests to the api and polluting the logs.
So in some cases this is a realy issue.
Best regards
Niklas