)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"2bee21e13d06607cef8367ce5e865caf9d78c02d","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":3,"id":"7780ecfb_8abbecdb","updated":"2025-05-14 11:25:42.000000000","message":"recheck timeout","commit_id":"7ffb63553ba81f091eb2aeb18138fecff9779ac1"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"60dc0af890409ba1db88abb4282b2bae47b6433c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"66271d1a_d3bfc2ac","updated":"2025-06-03 17:15:16.000000000","message":"As mentioned in IRC this is not correct. Official rules of the service catalog consumption and version discovery tells, that when relative link is used it should be relative to the url this doc was fetched from. That means that when version doc is exposed at `http://localhost/zaqar` a link `/v2` should result in `http://localhost/zaqar/v2` using concatenation. If the version url will also contain deployment prefix the resulting url will double this prefix. This is how keystoneauth/openstacksdk work now.\nEverything exposed by the service should be either using the absolute url (best case) or should be pretty much agnostic to the deployment location letting the proxy and catalog resolve the rest (i.e. web proxy exposing application at any prefix). https://opendev.org/openstack/keystoneauth/src/branch/master/keystoneauth1/discover.py#L481 is where this logic happens and it never checked whether the versioned url starts with \"/\" to try to identify whether this is a full relative path or relative relative","commit_id":"1343a05cd9193f8924c509835bc87f85d6e674bf"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"8700dfe8729eb9b1321640b9da0d597d88cee610","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"f7d37850_84fb2d50","updated":"2025-06-03 16:54:57.000000000","message":"Discussed this further on #openstack-keystone today. gtema pointed me to https://specs.openstack.org/openstack/api-sig/guidelines/consuming-catalog/version-discovery.html#expanding-endpoints which is pretty clear that what zaqar is currently doing is correct, and the fault lies in Gophercloud. I\u0027m going to leave this open a bit longer, but I think this will eventually be able to be abandoned.","commit_id":"1343a05cd9193f8924c509835bc87f85d6e674bf"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"1b361200cb07959f85c779ded57cbe959b3a7977","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":6,"id":"175b03a7_73e3f808","updated":"2025-06-03 16:09:38.000000000","message":"For same reason as the following patch. I should likely combine them.","commit_id":"1343a05cd9193f8924c509835bc87f85d6e674bf"}]}