)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":34149,"name":"Niklas Schwarz","email":"niklas.schwarz@inovex.de","username":"nschwarz"},"change_message_id":"d694159b35d2beee9c1598a94da4a3c8928fae90","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"e49ebdd7_06e62224","updated":"2025-01-13 13:21:38.000000000","message":"I just want to catch up with this issues.\nAny thoughts on how to tackle the issue, especially polluting the logs of keystone","commit_id":"a310c8e3a35b53a9e2f8c91a2f19e890385f1c99"},{"author":{"_account_id":34149,"name":"Niklas Schwarz","email":"niklas.schwarz@inovex.de","username":"nschwarz"},"change_message_id":"d81e0d99ba4516b0034c2a53269448c0d9358c0d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"7a80d461_da8a49a5","updated":"2024-10-30 09:56:56.000000000","message":"Thanks for the information.\n\nJust for the background why I try to fix this for keystone/identity: When you try to show a resource by the name the client always hits the /v3/\u003cresource\u003e/\u003cname_or_id\u003e endpoint first. When this request is not successful the client tries the /v3/\u003cresource\u003e?name\u003d\u003cname_or_id\u003e (with potential other parameters). When this is the normal behavior of the client then\n\n1. multiple requests to the endpoint are fired because we do not determine whether we have an id or a name, which could be possible for some resources (I think also projects, even if projects and domains are stored in the same table, there are two different endpoints in keystone [It is another discussion if domains can and should be fetched via the projects endpoint, imo this should not be possible]).\n\n2. More important for me is, when we send multiple requests to the api, also multiple database queries are executed, which can be prevented on an early stage, either in the client to validate for a name or id and send the correct request or by keystone itself to validate the input and respond with a BadRequest if the id is not in the correct format. This also has the advantage that the logs of the keystone server will not get polluted with exceptions when a query fails to get a resource by the id.\n\nIMO there are two ways to tackle the issue and prevent wasting of compute resources, even if it is done for only some of the resources.\n\n1. Adjust the clients interacting with the api\n2. Adjust the keystone server itself to tackle the issue, which also includes the adjustment of the client.\n\nBoth include to short circuit on the evaluation of the id but on different sides (client or server) maybe also on both sides.  \n\nPlease let me know if there are any plans to tackle the issue and what is the best way to do so","commit_id":"a310c8e3a35b53a9e2f8c91a2f19e890385f1c99"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"46546903e39aaa88cea90b515a8665773f85e709","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"905d4445_781fec63","updated":"2024-10-29 18:28:26.000000000","message":"there are so many resources where ID look like uuid but in reality aren\u0027t. There are so many resources with exceptions, i.e. in devstack there is domain with the id (surprise surprise) \"default\". There is nothing preventing giving names that are valid uuids. So the whole approach is not going to work reliably and introduce something that claims to save one roundtrip but is eventually misbehaving is not the way to go. Things that \"seem to look like\" should not be present in the code as they are extremely error prone \n\ndomains: uuid with allowed exception and possibility to override\nproject: uuid with people willing to have possibility to override\nec2creds: not uuid\ngroup - may be overriden by driver","commit_id":"a310c8e3a35b53a9e2f8c91a2f19e890385f1c99"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"5111ec90f1db2ba3989ce576c9a1bcb232142153","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f7fb87fb_44a0afe4","in_reply_to":"e49ebdd7_06e62224","updated":"2025-08-15 11:03:47.000000000","message":"Sorry, I missed this. I suspect this is something you should bring up on the mailing list since it\u0027s going to involve multiple projects. I agree that we should do better at attempting to use UUID-like objects directly, but we should likely survey the projects that we have to ensure they actually insist on UUIDs first (since some, like keystone, do not)","commit_id":"a310c8e3a35b53a9e2f8c91a2f19e890385f1c99"}],"openstackclient/identity/v3/trust.py":[{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"c8e4d7e24692f6101940ae8efbb9303adba5b3ac","unresolved":true,"context_lines":[{"line_number":244,"context_line":""},{"line_number":245,"context_line":"        if parsed_args.authuser:"},{"line_number":246,"context_line":"            if auth_ref:"},{"line_number":247,"context_line":"                print(auth_ref.user_id)"},{"line_number":248,"context_line":"                user \u003d common.find_user(identity_client, auth_ref.user_id)"},{"line_number":249,"context_line":"                # We need two calls here as we want trusts with"},{"line_number":250,"context_line":"                # either the trustor or the trustee set to current user"}],"source_content_type":"text/x-python","patch_set":1,"id":"367559a1_909708af","line":247,"updated":"2024-10-29 16:47:56.000000000","message":"whoops","commit_id":"a310c8e3a35b53a9e2f8c91a2f19e890385f1c99"}]}