Short-cutting obvious UUIDs would seem the obvious fix and could be
done in the SDK by e.g. providing a Resource.id_is_uuid attribute and a
corresponding change to the 'Proxy._find' method to respect this.
However, as we've pointed out (a) not all projects insist on UUIDs for
resource IDs, meaning the `id_is_uuid` attribute would need to be
evaluated on resource-by-resource basis and (b) you can't be sure that
a UUID is an actually the ID rather than the name, since a UUID can be
used as a name. I'd like to see if anyone has a clever suggestion for
how to avoid this.

Cheers,
Stephen

The only way to deal with that is to finally stop doing any guessing. User already perfectly knows what he has. So, like I am doing in the rust cli everywhere, there is explicitly RESOURCE_ID and RESOURCE_NAME with the user explicitly specifying one of those and the whole crappy guessing is gone. In Keystone the ID may be uuid or not depending on the backend. Due to that it is possible that 1 user would have an ID as UUID, while another one does not. We should finally stop making our own life more complex.

wrt stacktraces:

We had some iterations lately to remove some of them (i.e. on 404). I guess bad auth may still require some additional information context. Imagine that the fernet key is expired. Without verbose handling the admin will never be able to figure out that there is a real issue on the platform. Anyway, we can definitely reduce the noise.

Cheers,

Artem