)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":39166,"name":"Matthias Harzer","email":"matthias.harzer@inovex.de","username":"matthiasharzer"},"change_message_id":"ae80cad8db70d19ab80b0d12ea24af64063bee19","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"a7f9ba60_a95c37b1","updated":"2026-09-08 07:32:56.000000000","message":"A little follow-up on this, since the current behavior creates some inconveniences on our side:\n\nThe intention behind this patch was to remove a ~45 lines long keystone log-message, whenever a (existing) user is queried by name. This is due to \na) the SDK always first checking if a user (resource) with that ID exists and \nb) keystone raising a \"keystone.exception.UserNotFound\" exception and logs the exceptions stacktrace when trying to fetch a user by ID which does not exist.\n\nThis behavior currently clutters our keystone-logs massively and makes them virtually useless.\n\nSince the SDK is not the correct place to fix this, the question arises what the correct place would be. Do you have any suggestion @artem.goncharov@gmail.com? I would like to avoid creating further discussions in places not responsible for this problem.","commit_id":"2f6d0edca33f42ab0651dc919c2e6b71a0665bc0"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"7ef0c1985bd538b228205985c19e53caef1c3aa2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"0b39b66a_01405ad7","updated":"2026-09-07 08:58:51.000000000","message":"similar things were proposed multiple times, but OpenStack still stays the same - you can never check for uuid-like since e.g., keystone uses dashless format and allows arbitrary strings for IDs. Also nothing prevents resource name to be fully valid uuid which would completely break the logic here (id match is more important than the name match).","commit_id":"2f6d0edca33f42ab0651dc919c2e6b71a0665bc0"},{"author":{"_account_id":39166,"name":"Matthias Harzer","email":"matthias.harzer@inovex.de","username":"matthiasharzer"},"change_message_id":"75157c0e3298f1b8434cf544223724700d560bb1","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"003bfb4d_1334f3e7","in_reply_to":"0b39b66a_01405ad7","updated":"2026-09-07 09:53:03.000000000","message":"I thought my approach did not break existing behavior with arbitrary strings for IDs, but I just realized this is probably not possible on the SDK side. A keystone resource may have the ID of another resource as their name, which would lookup the resource by name first, thus yielding the resource with the matching name instead of the one with the matching ID. This violates ID match over name match. I\u0027ll abandon the patch.","commit_id":"2f6d0edca33f42ab0651dc919c2e6b71a0665bc0"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"9facddd6b34c0b7d07f20197995425a30abe92a2","unresolved":true,"context_lines":[],"source_content_type":"","patch_set":1,"id":"c559258d_2c24a50f","in_reply_to":"a7f9ba60_a95c37b1","updated":"2026-09-08 11:56:21.000000000","message":"We recently (half a year or so) fixed Keystone not to throw traces at 404, so this is the matter of update on your side (or backport those particular changes if you stuck on old release).\n\nThe proper solution to the issue is easy, but is not backwards compatible: the client is the one perfectly knowing which identifier it has: name or id. So instead of using the global method that accepts id or name the client should invoke get_XXX when it knows it handles with ID and go through the list when it knows the identifier is the name. Since something like this cannot be implemented cleanly in current projects, the rust reimplementation of sdk/cli/tui from scratch follow this new pattern. On the cli side the user need to be explicit: --user-name foobar|--user-id abc-def-xxx; --project-name|--project-id. But you can imagine the python openstackclient cannot simply adopt such pattern. Neither is python openstacksdk easily capable to adopt new interface without breaking existing users. We are still looking at starting generating python openstacksdk in the same way how rust sdk is being generated (eventually wrapping python to call rust under the hood), but that is still far. Such new step would allow us to introduce new interface though","commit_id":"2f6d0edca33f42ab0651dc919c2e6b71a0665bc0"}]}