)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"a5dba7401ee37a0bc8cd29b3004f0e053ff68a49","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"7958d2e1_5eace97c","updated":"2025-10-17 14:18:35.000000000","message":"LGTM; ninja-approving a docs-only change.","commit_id":"bfb46d531b375475413792da610fcbada5c17b84"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"6330523461b0304f32b6fe77d4d9c65bd2740efb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"27b47aea_406219df","updated":"2024-11-29 16:18:03.000000000","message":"folks, sorry, I don\u0027t think it\u0027s nearly enough just to edit documentation to match the reality.\n\nThis does not cover in any way a real impact on end users and other services which will happen during upgrade/migration.\n\nI somehow see that as a well-thought blueprint with a timeline across multiple releases, which will address process for migration from service type naming schema which was suggested for the last 7 years (not counting v2) to something different.\nAs well as how service type naming convention will be used in case of new API versions introduction in the future.\n\nLike doc change on itself is fine, but a lot much work must be done before we can say that it\u0027s a reality across the board.","commit_id":"bfb46d531b375475413792da610fcbada5c17b84"},{"author":{"_account_id":14200,"name":"Maksim Malchuk","email":"maksim.malchuk@gmail.com","username":"mmalchuk"},"change_message_id":"7fd7f5346cbbb6274c752740f7907188d4d2cb60","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"2372e409_15a50298","updated":"2025-04-28 08:18:44.000000000","message":"up","commit_id":"bfb46d531b375475413792da610fcbada5c17b84"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"a0811a5287c33c9eec39b132e15d688bb8c63ef2","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"58a49480_820850ba","in_reply_to":"27b47aea_406219df","updated":"2024-11-29 18:27:06.000000000","message":"I fail to see what any of this has to do with updating the install guide to reflect what we see as best practices. If other installers want to continue using an alias rather than the actual service type, that\u0027s fine: keystoneauth/openstacksdk will handle that, as will Gophercloud now. If they want to migrate like DevStack recently did then that\u0027s on them. I certainly am not going to drive changes across OSA, Kolla, etc.","commit_id":"bfb46d531b375475413792da610fcbada5c17b84"},{"author":{"_account_id":28619,"name":"Dmitriy Rabotyagov","email":"noonedeadpunk@gmail.com","username":"noonedeadpunk"},"change_message_id":"2b18a9f1f86dee56c1e8294400b4337926b22d9c","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"cefe617d_c17469e3","in_reply_to":"58a49480_820850ba","updated":"2024-11-29 18:55:52.000000000","message":"Ok, I think I am just very skeptical about clients and other services handling aliases properly. And as you\u0027ve mentioned earlier - couple got broken indeed.\n\nAnd now we are changing very established \"best practices\" by saying they always were like that.\n\nI just see service types as smth very established which should not change without *very* good reason.\nIt\u0027s service names that can be anything we want. Not _types_.\n\nI can imagine all kind of non-openstack things which would rely to find a service in keystone catalog under specific type name.\n\nBut you\u0027re right that documentation patch indeed not related directly to the rest of the discussion","commit_id":"bfb46d531b375475413792da610fcbada5c17b84"}]}