While highly theoretical, it indeed can happen. Actually the same can also happen with uuid in absolutely the same way - just let users create a user with the name in the uuid form (who knows, maybe for some test) and the card house is falling apart.

It is actually not such a breaking change as you might think of:

1) there is rust cli which allows us to start using new interface while leaving legacy loads not affected

2) technically the change would be about adding --name and --id parameters to the diverse calls while leaving previous functionality not affected. It may not be always possible, but something like `user show <name_or_id>`, `user show --name <NAME>`, `user show --id <ID>` should be actually not break anything.

But anyway - a lot of people recognize the problem with the current approach and fear breaking it introducing something better - this is something that honestly annoys me. If something does not work conceptually it should be removed and not kept artificially alive forever. Why are we trying to desperately make our own life so complex.

Artem

On Tue, 19 Aug 2025 at 09:16, Niklas Schwarz <niklas.schwarz@inovex.de> wrote:

I agree that one way to tackle the issue is to stop guessing what is provided by the user but this would include some major breaking changes in the sdk and client. I would be fine with this solution.

The problem with keystone is that if the a request is issued e.g. `user show <name>` with a mysql db as the backend the name is passed in the query and the query raises the exception because
it expects to return exactly one user but with the id but it will not find the user because of a name passed in. There is no validation on the server. The values are just passed to the query and we hopefully
get back an answer. And such requests are polluting the logs of keystone and then in the long term you will not find any information in the
logs. But I have to look in the logs of newer versions of openstack than caracal to check what has been done to remove some of the exceptions.

But just one question with the different backends for keystone pointed out by artem: Wouldn't it be possible that one user has an id which is the name of an other user. This is highly theoretical and
I think it wont happen but it is a consideration and an argument to move away from the guessing what a user provides us and switch to an approach that the user must exactly define what will be provided.

Cheers ,
Niklas