)]}'
{"/PATCHSET_LEVEL":[{"author":{"_account_id":29632,"name":"Carlos Eduardo","email":"ces.eduardo98@gmail.com","username":"silvacarlos"},"change_message_id":"1aaf3cea5c3c25c057ac5dcc2dfa5d3376e22226","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"f38e33c4_8629f032","updated":"2026-03-06 18:29:19.000000000","message":"LGTM, thanks Stephen","commit_id":"c69ee125b7e102631989d230211fa149641564f6"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"b622f4a3a4fd6293b89db752372edf479783c69e","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"c0487063_82680ea8","updated":"2026-04-26 06:40:18.000000000","message":"Hi Stephen, \n\nThank you for moving this to \"release independent\". I have no concerns with the intent here, but I do have some questions:\n\n1) Generally, we strive hard to support OSC commands today as soon as the server ships new API behavior. Moving this command layer to openstackclient could introduce a lag. How do other project teams deal with this today? \n\nI believe CLI changes can land at anytime and people should freely adopt the newer CLI and gain the new functionality. However, in reality, distros tend to pull from a specific branch of the CLI - which makes it hard for consumers to get newer features past the release cycle boundary :/ \n\n2) We were hoping to help you with this; we proposed this project for an upcoming Outreachy internship. We got an overwhelming response in terms of applicants; however, the internship isn\u0027t a given unless we\u0027ve identified funding. Hope this is fine by you. If we don\u0027t get an intern, we\u0027d like to lend a hand nonetheless. \n\n3) You mention that we don\u0027t intend on replacing manilaclient SDK during this migration. However, you allude to doing that separately, in the future? What are the downsides if this never happens? I ask because it\u0027s been quite hard convincing folks to adopt openstackclient - took us years until they saw tangible benefits. manilaclient is quite as entrenched in operations today.. migrating to openstacksdk could be painful, and, we enforce a new development model too for contributors:\n\n- any new API interaction has to be supported first in openstacksdk\n- an openstacksdk release has to be tagged with the feature in it\n- openstackclient can then bump its minimum requirement of openstacksdk and then support the CLI interfaces for the corresponding feature\n\nQuite cumbersome, don\u0027t you think? Do you get used to this? Is it actually easier than I\u0027m picturing?","commit_id":"cb0366129b3dfde86584fbf7c6b170b777fd676e"},{"author":{"_account_id":29632,"name":"Carlos Eduardo","email":"ces.eduardo98@gmail.com","username":"silvacarlos"},"change_message_id":"e29d460a5b807d831e853e35eb93017439af5f61","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"630d3dbb_ff704044","updated":"2026-05-04 11:03:01.000000000","message":"Let\u0027s get this in. Thanks, Stephen!","commit_id":"cb0366129b3dfde86584fbf7c6b170b777fd676e"},{"author":{"_account_id":15334,"name":"Stephen Finucane","display_name":"stephenfin","email":"stephenfin@redhat.com","username":"sfinucan"},"change_message_id":"586460d95d62a10dc19ef53c34a0e545701adbdb","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":2,"id":"92df3bb5_03ff38c5","in_reply_to":"c0487063_82680ea8","updated":"2026-04-27 10:52:43.000000000","message":"\u003e Hi Stephen, \n\u003e \n\u003e Thank you for moving this to \"release independent\". I have no concerns with the intent here, but I do have some questions:\n\u003e \n\u003e 1) Generally, we strive hard to support OSC commands today as soon as the server ships new API behavior. Moving this command layer to openstackclient could introduce a lag. How do other project teams deal with this today?\n\nBoth SDK and OSC use the `cycle-with-intermediary` release model, so we just cut releases pretty aggressively. It hasn\u0027t proven an issue so long as people actually do the work to get patches proposed for the projects and respond to feedback (the lack of follow-up was the blocker on the server share patches).\n\n\u003e I believe CLI changes can land at anytime and people should freely adopt the newer CLI and gain the new functionality. However, in reality, distros tend to pull from a specific branch of the CLI - which makes it hard for consumers to get newer features past the release cycle boundary :/ \n\nI believe this is true for both manilaclient and OSC? We try to avoid adding any new deprecations or removing code after M2 but we accept patches for new features pretty much all the time.\n\n\u003e 2) We were hoping to help you with this; we proposed this project for an upcoming Outreachy internship. We got an overwhelming response in terms of applicants; however, the internship isn\u0027t a given unless we\u0027ve identified funding. Hope this is fine by you. If we don\u0027t get an intern, we\u0027d like to lend a hand nonetheless. \n\nCarlos filled me in on this. There\u0027s no issue with this, but I suspect the initial migration of commands from manilaclient to OSC will be rather mechanical and the more interesting work would be the change on underlying library (to SDK).\n\n\u003e 3) You mention that we don\u0027t intend on replacing manilaclient SDK during this migration. However, you allude to doing that separately, in the future? What are the downsides if this never happens?\n\nThe largest downside is that there is no motivation to complete the long tail of SDK gaps. The CLIs tends to cover virtually the entirety of a service\u0027s API, so migrating to SDK can be very useful in highlighting gaps.\n\n\u003e I ask because it\u0027s been quite hard convincing folks to adopt openstackclient - took us years until they saw tangible benefits. manilaclient is quite as entrenched in operations today.. migrating to openstacksdk could be painful, and, we enforce a new development model too for contributors:\n\u003e \n\u003e - any new API interaction has to be supported first in openstacksdk\n\u003e - an openstacksdk release has to be tagged with the feature in it\n\u003e - openstackclient can then bump its minimum requirement of openstacksdk and then support the CLI interfaces for the corresponding feature\n\u003e \n\u003e Quite cumbersome, don\u0027t you think? Do you get used to this? Is it actually easier than I\u0027m picturing?\n\nFirstly, why is this not already part of your contributor guidance? 😅 I know you had interns working on adding Manila support to SDK in the past: why invest that time in closing the gap only to allow it to start growing again by not adding support for new API microversions?\n\nSecondly, this is what already exists today for Nova, Neutron and Glance. I would certainly prefer if SDK and OSC were packaged and versioned together (and have proposed exactly this previously) but in practice, it hasn\u0027t proven complicated. We have robust release tooling and can comfortably get a release of SDK addressing a feature or bugfix in a day or two. I would, however, suggest that deprecating manilaclient (SDK) should be on the cards, since managing two SDKs is a bit mad and, with its largest user (the shell) migrated, there will be decreasingly few reasons to keep it around. I didn\u0027t touch on that here though since that\u0027s a different conversation.","commit_id":"cb0366129b3dfde86584fbf7c6b170b777fd676e"}],"specs/gazpacho/integrate-manilaclient.rst":[{"author":{"_account_id":29632,"name":"Carlos Eduardo","email":"ces.eduardo98@gmail.com","username":"silvacarlos"},"change_message_id":"1aaf3cea5c3c25c057ac5dcc2dfa5d3376e22226","unresolved":true,"context_lines":[{"line_number":104,"context_line":"Work Items"},{"line_number":105,"context_line":"----------"},{"line_number":106,"context_line":""},{"line_number":107,"context_line":"We need to do the initial bootstrapping of the client in OSC but once done, commands can be migrated to OSC incrementally using the following pattern:"},{"line_number":108,"context_line":""},{"line_number":109,"context_line":"* Copy the commands module and tests for same (e.g. ``manilaclient/osc/v2/services.py`` and ``manilaclient/tests/unit/osc/v2/test_services.py``) to their respective locations in OSC (e.g. ``openstackclient/share/v2/`` and ``openstackclient/tests/unit/share/v2/``)"},{"line_number":110,"context_line":""}],"source_content_type":"text/x-rst","patch_set":1,"id":"dae5fc8b_3a3843b1","line":107,"range":{"start_line":107,"start_character":0,"end_line":107,"end_character":2},"updated":"2026-03-06 18:29:19.000000000","message":"nit: too many characters in the lines here and below, so that impacts the reading. The rendering looks fine though","commit_id":"c69ee125b7e102631989d230211fa149641564f6"}]}