)]}'
{"resolutions/20201028-openstackclient-tc-policy.rst":[{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fff0065eb3dafe04b31c6dcd81f2270d7deef589","unresolved":false,"context_lines":[{"line_number":5,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":6,"context_line":"client instead of continuing to maintain the individual python-*clients for each of the"},{"line_number":7,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":8,"context_line":"clients so as to deprecate and remove the project specific clients."},{"line_number":9,"context_line":""},{"line_number":10,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":11,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_6e12890b","line":8,"updated":"2020-10-27 17:24:58.000000000","message":"This seems weird to me, since there are many more than two clients, but I obviously know what you mean. Maybe \"between the two client approaches\" or something?","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"07bcbbe50712707c36efee4ba0f8510d6783e7e7","unresolved":false,"context_lines":[{"line_number":5,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":6,"context_line":"client instead of continuing to maintain the individual python-*clients for each of the"},{"line_number":7,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":8,"context_line":"clients so as to deprecate and remove the project specific clients."},{"line_number":9,"context_line":""},{"line_number":10,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":11,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_021c8410","line":8,"in_reply_to":"3f65232a_14e7a242","updated":"2020-10-27 22:36:59.000000000","message":"That is a good question. I guess I was thinking they would not be required as packages for plugins, but maybe that\u0027s wrong.","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":7198,"name":"Jay Bryant","email":"jungleboyj@electronicjungle.net","username":"jsbryant"},"change_message_id":"755a8334a14a5518a10917116bd4da6eb7c36f5e","unresolved":false,"context_lines":[{"line_number":5,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":6,"context_line":"client instead of continuing to maintain the individual python-*clients for each of the"},{"line_number":7,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":8,"context_line":"clients so as to deprecate and remove the project specific clients."},{"line_number":9,"context_line":""},{"line_number":10,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":11,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_ce03dd41","line":8,"in_reply_to":"3f65232a_6e12890b","updated":"2020-10-27 17:50:00.000000000","message":"Agree.","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"8ea515182561ed5dc26070422c8fd12e9e029a25","unresolved":false,"context_lines":[{"line_number":5,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":6,"context_line":"client instead of continuing to maintain the individual python-*clients for each of the"},{"line_number":7,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":8,"context_line":"clients so as to deprecate and remove the project specific clients."},{"line_number":9,"context_line":""},{"line_number":10,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":11,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_8241b40e","line":8,"in_reply_to":"3f65232a_6e12890b","updated":"2020-10-27 22:29:20.000000000","message":"Done","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":13252,"name":"Dr. Jens Harbott","display_name":"Jens Harbott (frickler)","email":"frickler@offenerstapel.de","username":"jrosenboom"},"change_message_id":"00ac32c709620dfeceb9c91ebdb479289185f458","unresolved":false,"context_lines":[{"line_number":5,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":6,"context_line":"client instead of continuing to maintain the individual python-*clients for each of the"},{"line_number":7,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":8,"context_line":"clients so as to deprecate and remove the project specific clients."},{"line_number":9,"context_line":""},{"line_number":10,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":11,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_14e7a242","line":8,"in_reply_to":"3f65232a_ce03dd41","updated":"2020-10-27 19:05:17.000000000","message":"Maybe also be more specific in that OSC will likely not cover all projects, but will continue to use the python-*client packages as plugins to provide specific commands for those projects? Or is that intended to change, too? So the correct wording would only call for the CLI part of the python*client pkgs to be removed.","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fff0065eb3dafe04b31c6dcd81f2270d7deef589","unresolved":false,"context_lines":[{"line_number":12,"context_line":"OpenStack feel disjointed and overly complex."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"In order to better support the user experience and encourage adoption of new"},{"line_number":15,"context_line":"users, we will have a two fold policy."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Firstly, going forward, OpenStack services will focus on enabling  all user"},{"line_number":18,"context_line":"documentation will make use of the OpenStackClient and not the python-* clients."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_0e64b5e3","line":15,"range":{"start_line":15,"start_character":22,"end_line":15,"end_character":30},"updated":"2020-10-27 17:24:58.000000000","message":"I believe this should be \"twofold\":\n\nhttps://www.merriam-webster.com/dictionary/twofold","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fff0065eb3dafe04b31c6dcd81f2270d7deef589","unresolved":false,"context_lines":[{"line_number":11,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"},{"line_number":12,"context_line":"OpenStack feel disjointed and overly complex."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"In order to better support the user experience and encourage adoption of new"},{"line_number":15,"context_line":"users, we will have a two fold policy."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Firstly, going forward, OpenStack services will focus on enabling  all user"},{"line_number":18,"context_line":"documentation will make use of the OpenStackClient and not the python-* clients."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_eefdf9b1","line":15,"range":{"start_line":14,"start_character":61,"end_line":15,"end_character":5},"updated":"2020-10-27 17:24:58.000000000","message":"I think you mean \"adoption by new users [of the unified client]\" right? We\u0027re not adopting any users are we?!","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"8ea515182561ed5dc26070422c8fd12e9e029a25","unresolved":false,"context_lines":[{"line_number":12,"context_line":"OpenStack feel disjointed and overly complex."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"In order to better support the user experience and encourage adoption of new"},{"line_number":15,"context_line":"users, we will have a two fold policy."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Firstly, going forward, OpenStack services will focus on enabling  all user"},{"line_number":18,"context_line":"documentation will make use of the OpenStackClient and not the python-* clients."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_223a6097","line":15,"range":{"start_line":15,"start_character":22,"end_line":15,"end_character":30},"in_reply_to":"3f65232a_0e64b5e3","updated":"2020-10-27 22:29:20.000000000","message":"Done","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"8ea515182561ed5dc26070422c8fd12e9e029a25","unresolved":false,"context_lines":[{"line_number":11,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"},{"line_number":12,"context_line":"OpenStack feel disjointed and overly complex."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"In order to better support the user experience and encourage adoption of new"},{"line_number":15,"context_line":"users, we will have a two fold policy."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Firstly, going forward, OpenStack services will focus on enabling  all user"},{"line_number":18,"context_line":"documentation will make use of the OpenStackClient and not the python-* clients."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_42379cb1","line":15,"range":{"start_line":14,"start_character":61,"end_line":15,"end_character":5},"in_reply_to":"3f65232a_eefdf9b1","updated":"2020-10-27 22:29:20.000000000","message":"Done","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fff0065eb3dafe04b31c6dcd81f2270d7deef589","unresolved":false,"context_lines":[{"line_number":14,"context_line":"In order to better support the user experience and encourage adoption of new"},{"line_number":15,"context_line":"users, we will have a two fold policy."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Firstly, going forward, OpenStack services will focus on enabling  all user"},{"line_number":18,"context_line":"documentation will make use of the OpenStackClient and not the python-* clients."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Secondly, all ci tooling should use the OpenStackClient to further the efforts that the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_2e9ed1b7","line":17,"range":{"start_line":17,"start_character":43,"end_line":17,"end_character":47},"updated":"2020-10-27 17:24:58.000000000","message":"I dunno what the prior art says, but should this be \"should\"? Like, I\u0027m not sure if these are supposed to be declarative or aspirational.","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fff0065eb3dafe04b31c6dcd81f2270d7deef589","unresolved":false,"context_lines":[{"line_number":14,"context_line":"In order to better support the user experience and encourage adoption of new"},{"line_number":15,"context_line":"users, we will have a two fold policy."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Firstly, going forward, OpenStack services will focus on enabling  all user"},{"line_number":18,"context_line":"documentation will make use of the OpenStackClient and not the python-* clients."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Secondly, all ci tooling should use the OpenStackClient to further the efforts that the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_ee5e9910","line":17,"range":{"start_line":17,"start_character":65,"end_line":17,"end_character":67},"updated":"2020-10-27 17:24:58.000000000","message":"s/  / /","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"8ea515182561ed5dc26070422c8fd12e9e029a25","unresolved":false,"context_lines":[{"line_number":14,"context_line":"In order to better support the user experience and encourage adoption of new"},{"line_number":15,"context_line":"users, we will have a two fold policy."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Firstly, going forward, OpenStack services will focus on enabling  all user"},{"line_number":18,"context_line":"documentation will make use of the OpenStackClient and not the python-* clients."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Secondly, all ci tooling should use the OpenStackClient to further the efforts that the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_6244581c","line":17,"range":{"start_line":17,"start_character":43,"end_line":17,"end_character":47},"in_reply_to":"3f65232a_2e9ed1b7","updated":"2020-10-27 22:29:20.000000000","message":"Having never written a resolution before, I wasn\u0027t sure, but I changed it to \u0027should\u0027 in patchset 2.","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"8ea515182561ed5dc26070422c8fd12e9e029a25","unresolved":false,"context_lines":[{"line_number":14,"context_line":"In order to better support the user experience and encourage adoption of new"},{"line_number":15,"context_line":"users, we will have a two fold policy."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Firstly, going forward, OpenStack services will focus on enabling  all user"},{"line_number":18,"context_line":"documentation will make use of the OpenStackClient and not the python-* clients."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Secondly, all ci tooling should use the OpenStackClient to further the efforts that the"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_a2c0307e","line":17,"range":{"start_line":17,"start_character":65,"end_line":17,"end_character":67},"in_reply_to":"3f65232a_ee5e9910","updated":"2020-10-27 22:29:20.000000000","message":"Done","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fff0065eb3dafe04b31c6dcd81f2270d7deef589","unresolved":false,"context_lines":[{"line_number":15,"context_line":"users, we will have a two fold policy."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Firstly, going forward, OpenStack services will focus on enabling  all user"},{"line_number":18,"context_line":"documentation will make use of the OpenStackClient and not the python-* clients."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Secondly, all ci tooling should use the OpenStackClient to further the efforts that the"},{"line_number":21,"context_line":"minimal viable workflows are unified on a single client."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_8ef3a50a","line":18,"range":{"start_line":18,"start_character":0,"end_line":18,"end_character":13},"updated":"2020-10-27 17:24:58.000000000","message":"This sentence is \"enabling all user documentation will make use of\", which I think is probably from conference brain. Maybe something like:\n\n \"OpenStack projects will focus on ensuring that all user-oriented\n documents use openstackclient wherever possible, close gaps in it\n where necessary to enable this, and call out specific and\n intentional uses of the python-* clients as transitional until\n support can be added.\"","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"8ea515182561ed5dc26070422c8fd12e9e029a25","unresolved":false,"context_lines":[{"line_number":15,"context_line":"users, we will have a two fold policy."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"Firstly, going forward, OpenStack services will focus on enabling  all user"},{"line_number":18,"context_line":"documentation will make use of the OpenStackClient and not the python-* clients."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Secondly, all ci tooling should use the OpenStackClient to further the efforts that the"},{"line_number":21,"context_line":"minimal viable workflows are unified on a single client."}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_c2c56c90","line":18,"range":{"start_line":18,"start_character":0,"end_line":18,"end_character":13},"in_reply_to":"3f65232a_8ef3a50a","updated":"2020-10-27 22:29:20.000000000","message":"Done","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"fff0065eb3dafe04b31c6dcd81f2270d7deef589","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Firstly, going forward, OpenStack services will focus on enabling  all user"},{"line_number":18,"context_line":"documentation will make use of the OpenStackClient and not the python-* clients."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Secondly, all ci tooling should use the OpenStackClient to further the efforts that the"},{"line_number":21,"context_line":"minimal viable workflows are unified on a single client."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"This resolution is not going to dictate a completion date, but is to ensure that we make"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_ee4fb931","line":20,"range":{"start_line":20,"start_character":14,"end_line":20,"end_character":16},"updated":"2020-10-27 17:24:58.000000000","message":"CI\n\nAs I mentioned in the call, I think we should justify this requirement to avoid looking too much like a specific grievance and more of a timeless ambition. Maybe something like:\n\n \"In an effort to dogfood our own tooling for the purposes of\n highlighting any existing unrealized gaps in user workflows,\n anything in our upstream CI that interacts with an openstack\n service should use openstackclient wherever possible, and when\n not possible, a bug should be filed highlighting a feature gap.\"","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"8ea515182561ed5dc26070422c8fd12e9e029a25","unresolved":false,"context_lines":[{"line_number":17,"context_line":"Firstly, going forward, OpenStack services will focus on enabling  all user"},{"line_number":18,"context_line":"documentation will make use of the OpenStackClient and not the python-* clients."},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"Secondly, all ci tooling should use the OpenStackClient to further the efforts that the"},{"line_number":21,"context_line":"minimal viable workflows are unified on a single client."},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"This resolution is not going to dictate a completion date, but is to ensure that we make"}],"source_content_type":"text/x-rst","patch_set":3,"id":"3f65232a_62cf38b0","line":20,"range":{"start_line":20,"start_character":14,"end_line":20,"end_character":16},"in_reply_to":"3f65232a_ee4fb931","updated":"2020-10-27 22:29:20.000000000","message":"Done","commit_id":"ab9592ee7c50e1c91eeaa0125012aab4ebe0b3ea"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"9af4f813a0e0df754461153348649c76227acc26","unresolved":false,"context_lines":[{"line_number":14,"context_line":"users of the unified client, we will have a twofold policy."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Firstly, going forward, OpenStack services should focus on ensuring that all"},{"line_number":17,"context_line":"user-oriented documents use OpenStackClient wherever possible, close gaps in it"},{"line_number":18,"context_line":"where necessary to enable this, and call out specific and intentional uses of the"},{"line_number":19,"context_line":"python-* clients as transitional until support can be added."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1f621f24_014cc9c5","line":17,"range":{"start_line":17,"start_character":28,"end_line":17,"end_character":43},"updated":"2020-10-28 23:03:02.000000000","message":"Maybe expand this to \"OpenStackClient CLIs\" to address the comments about client libraries vs. client tooling?","commit_id":"d90b91fdaa550b4899b35c7a1895efeb5f8275f3"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"41be6d1e82b4ff02415fb9ea7903817d4d02917b","unresolved":false,"context_lines":[{"line_number":14,"context_line":"users of the unified client, we will have a twofold policy."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Firstly, going forward, OpenStack services should focus on ensuring that all"},{"line_number":17,"context_line":"user-oriented documents use OpenStackClient wherever possible, close gaps in it"},{"line_number":18,"context_line":"where necessary to enable this, and call out specific and intentional uses of the"},{"line_number":19,"context_line":"python-* clients as transitional until support can be added."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":5,"id":"1f621f24_b4e1472d","line":17,"range":{"start_line":17,"start_character":28,"end_line":17,"end_character":43},"in_reply_to":"1f621f24_014cc9c5","updated":"2020-11-09 20:37:04.000000000","message":"Done","commit_id":"d90b91fdaa550b4899b35c7a1895efeb5f8275f3"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"71ab87885766fdd6ee7962feff0eaefcd4a5c43f","unresolved":false,"context_lines":[{"line_number":18,"context_line":"where necessary to enable this, and call out specific and intentional uses of the"},{"line_number":19,"context_line":"python-* clients as transitional until support can be added."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Secondly, in an effort to dogood our own tooling for the purposes of highlighting any"},{"line_number":22,"context_line":"existing unrealized gaps in user workflows, anything in our upstream CI that interacts"},{"line_number":23,"context_line":"with an openstack service should use the OpenStackClient wherever possible. When"},{"line_number":24,"context_line":"this is not possible, a bug should be filed highlighting the feature gap."}],"source_content_type":"text/x-rst","patch_set":5,"id":"3f65232a_3d79e1fb","line":21,"range":{"start_line":21,"start_character":26,"end_line":21,"end_character":32},"updated":"2020-10-28 01:17:41.000000000","message":"*dogfood\n\nNot sure this is an idiom that translates well for non-native speakers.","commit_id":"d90b91fdaa550b4899b35c7a1895efeb5f8275f3"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"9af4f813a0e0df754461153348649c76227acc26","unresolved":false,"context_lines":[{"line_number":18,"context_line":"where necessary to enable this, and call out specific and intentional uses of the"},{"line_number":19,"context_line":"python-* clients as transitional until support can be added."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Secondly, in an effort to dogood our own tooling for the purposes of highlighting any"},{"line_number":22,"context_line":"existing unrealized gaps in user workflows, anything in our upstream CI that interacts"},{"line_number":23,"context_line":"with an openstack service should use the OpenStackClient wherever possible. When"},{"line_number":24,"context_line":"this is not possible, a bug should be filed highlighting the feature gap."}],"source_content_type":"text/x-rst","patch_set":5,"id":"1f621f24_c1513165","line":21,"range":{"start_line":21,"start_character":26,"end_line":21,"end_character":32},"in_reply_to":"3f65232a_3d79e1fb","updated":"2020-10-28 23:03:02.000000000","message":"I feel like this is really common in the IT industry, but we could also provide a footnote if it would help:\n\nhttps://www.techopedia.com/definition/30784/dogfooding","commit_id":"d90b91fdaa550b4899b35c7a1895efeb5f8275f3"},{"author":{"_account_id":308,"name":"Thierry Carrez","email":"thierry@openstack.org","username":"ttx"},"change_message_id":"dd99cc53b0f26965cff2d476a9eddbfe17032d77","unresolved":false,"context_lines":[{"line_number":24,"context_line":"this is not possible, a bug should be filed highlighting the feature gap."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"This resolution is not going to dictate a completion date, but is to ensure that we make"},{"line_number":27,"context_line":"forward progress in that direction."}],"source_content_type":"text/x-rst","patch_set":5,"id":"1f621f24_918d667d","line":27,"range":{"start_line":27,"start_character":0,"end_line":27,"end_character":16},"updated":"2020-11-05 10:07:22.000000000","message":"suggestion: \"continuous forward progress\"","commit_id":"d90b91fdaa550b4899b35c7a1895efeb5f8275f3"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"41be6d1e82b4ff02415fb9ea7903817d4d02917b","unresolved":false,"context_lines":[{"line_number":24,"context_line":"this is not possible, a bug should be filed highlighting the feature gap."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"This resolution is not going to dictate a completion date, but is to ensure that we make"},{"line_number":27,"context_line":"forward progress in that direction."}],"source_content_type":"text/x-rst","patch_set":5,"id":"1f621f24_54ca73a0","line":27,"range":{"start_line":27,"start_character":0,"end_line":27,"end_character":16},"in_reply_to":"1f621f24_918d667d","updated":"2020-11-09 20:37:04.000000000","message":"Done","commit_id":"d90b91fdaa550b4899b35c7a1895efeb5f8275f3"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"1bae08a7eb77988d1f0aaedefc0c3d50689750da","unresolved":false,"context_lines":[{"line_number":1,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":2,"context_line":"2020-10-28 OpenStackClient TC Policy"},{"line_number":3,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":4,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":5,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":6,"context_line":"OpenStack services and the best way to approach reaching parity between the two"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1f621f24_f31ff0b4","line":3,"updated":"2020-11-17 21:44:33.000000000","message":"It would be useful to say somewhere what is this openstackclient we\u0027re speaking of, for example,  \"OpenStackClient (aka OSC) is a command-line client for OpenStack that brings the command set for Compute, Identity, Image, Object Storage and Block Storage APIs together in a single shell with a uniform command structure.\"[0]\n\n[0] https://docs.openstack.org/python-openstackclient/latest/","commit_id":"8995cb2810a8b9fea9ac945fde99288426767f16"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"ef1a2bfcb3122aab8f8f9c8d877c45e053dbcb9f","unresolved":false,"context_lines":[{"line_number":1,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":2,"context_line":"2020-10-28 OpenStackClient TC Policy"},{"line_number":3,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":4,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":5,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":6,"context_line":"OpenStack services and the best way to approach reaching parity between the two"}],"source_content_type":"text/x-rst","patch_set":6,"id":"fffc6b78_f249a860","line":3,"in_reply_to":"1f621f24_f31ff0b4","updated":"2020-11-18 18:57:21.000000000","message":"Done","commit_id":"8995cb2810a8b9fea9ac945fde99288426767f16"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"1bae08a7eb77988d1f0aaedefc0c3d50689750da","unresolved":false,"context_lines":[{"line_number":4,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":5,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":6,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":7,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":10,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1f621f24_13654c46","line":7,"range":{"start_line":7,"start_character":27,"end_line":7,"end_character":76},"updated":"2020-11-17 21:44:33.000000000","message":"Given that the OpenStackClient is explicitly a CLI, I assume that you are proposing that the project-specific CLIs be deprecated and removed?  Or are you proposing that the python-x clients be removed in toto because they are to be replaced by the OpenStack SDK?  It would be helpful to be clear here, because many of the arguments advanced in this document in favor of the OSC (uniformity, etc.) can also be proposed in favor of the SDK.  I\u0027d like to know exactly what the TC is thinking here.","commit_id":"8995cb2810a8b9fea9ac945fde99288426767f16"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"ef1a2bfcb3122aab8f8f9c8d877c45e053dbcb9f","unresolved":false,"context_lines":[{"line_number":4,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":5,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":6,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":7,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":10,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":6,"id":"fffc6b78_129f0cb5","line":7,"range":{"start_line":7,"start_character":27,"end_line":7,"end_character":76},"in_reply_to":"1f621f24_13654c46","updated":"2020-11-18 18:57:21.000000000","message":"I would think python-*clients would be removed except where there is a standalone service like Ironic. Maybe other TC members can share their thoughts here too so that we are all on the same page.","commit_id":"8995cb2810a8b9fea9ac945fde99288426767f16"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"e3f5db107e8627afae987ec429ae5546711c10d4","unresolved":false,"context_lines":[{"line_number":4,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":5,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":6,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":7,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":10,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":6,"id":"7e6fac09_761fb23e","line":7,"range":{"start_line":7,"start_character":27,"end_line":7,"end_character":76},"in_reply_to":"528eaf30_fdff9396","updated":"2020-12-03 19:20:37.000000000","message":"I think this is point where most confusion was and people had multiple opinions.\n\nI think it is better to mention this approach clearly in this resolution to have all in same page.","commit_id":"8995cb2810a8b9fea9ac945fde99288426767f16"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"ff062fef18f147b247e2f04d1d1e23bc5a0e1973","unresolved":false,"context_lines":[{"line_number":4,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":5,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":6,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":7,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":10,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":6,"id":"fffc6b78_289294f7","line":7,"range":{"start_line":7,"start_character":27,"end_line":7,"end_character":76},"in_reply_to":"fffc6b78_129f0cb5","updated":"2020-11-19 15:14:56.000000000","message":"Kendall: I didn\u0027t fully get your points. Do you suggest to drop python-*clients for python bindings too?\n\nThe neutron team had the similar discussion when migrating neutron CLI to OSC. python-neutronclient provides python bindings for the networking API.\nOur consensuses in the neutron team are:\n- python-neutronclient repo continues to provide python bindings for consumers like nova (If we need more python bindings for integrations with services like nova, we will add new bindings, but if it is for CLI implementations we should not do it.)\n- OpenStackSDK should provide python bindings for OSC\n- python bindings in python-neutronclient repo should not provide python bindings for OSC\n\nThe above is the general consensus in the neutron team, but the neutron team does not cover all as we still have OSC plugin in the python-neutronclient repo for advanced services. This is a different topic and I don\u0027t cover it here.","commit_id":"8995cb2810a8b9fea9ac945fde99288426767f16"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"804ba3c5f5a8395d1eac0c386b471ad8576c0f08","unresolved":false,"context_lines":[{"line_number":4,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":5,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":6,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":7,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":10,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":6,"id":"fffc6b78_e33f0db3","line":7,"range":{"start_line":7,"start_character":27,"end_line":7,"end_character":76},"in_reply_to":"fffc6b78_289294f7","updated":"2020-11-19 15:31:04.000000000","message":"Akihiro: hmm, I am not sure this should the way in the long run. SDK provides binding for every potential client. Nova already uses it to communicate with other services (maybe not everything, but definitely some)\nWhat is the sense of having multiple projects doing absolutely same?\nWhat we hopefully want to achieve is to give users a single interface communicating with the cloud. If we drop every other CLI client - that\u0027s good, but the next question will arise - what about python clients? In my head the target is to have only OSC as CLI (yes, with plugins) and SDK (yes, with plugins) for every other type of python based communication (both for the end user and between services). This whole microversion handling at the very least is not coming out of the box otherwise.","commit_id":"8995cb2810a8b9fea9ac945fde99288426767f16"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"73a903cd196554453948db6b7f88f3f9dc125aeb","unresolved":false,"context_lines":[{"line_number":4,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":5,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":6,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":7,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":10,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":6,"id":"528eaf30_fdff9396","line":7,"range":{"start_line":7,"start_character":27,"end_line":7,"end_character":76},"in_reply_to":"fffc6b78_e33f0db3","updated":"2020-11-27 04:02:56.000000000","message":"Artem, I agree in general that it is better not to have duplicated functionalities (both in openstacksdk and python-*client).\nWhat I mentioned above is what was discussed in the neutron team more than three years ago when we move the CLI functionalities to OSC. At that time, openstacksdk was not mature enough, so we tried to minimize the impact to other service projects like nova. Thus we decided to keep neutron python bindings in python-neutronclient repository.\nThe situation has changed a lot since then. Individual service projects like nova can decide when and how they switch python bindings from python-*client to openstacksdk separately. It is a good news that nova already started to use openstacksdk in its server side code. I didn\u0027t know that.\n\nOn the other hand, this resolution is about the stance on the future of CLI, so a discussion on SDK might be beyond the scope of the resolution. This kind of questions raised, so it looks better to me to clarify it in some way.","commit_id":"8995cb2810a8b9fea9ac945fde99288426767f16"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"1bae08a7eb77988d1f0aaedefc0c3d50689750da","unresolved":false,"context_lines":[{"line_number":13,"context_line":"In order to better support the user experience and encourage adoption by new"},{"line_number":14,"context_line":"users of the unified client, we will have a twofold policy."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Firstly, going forward, OpenStack services should focus on ensuring that all"},{"line_number":17,"context_line":"user-oriented documents use OpenStackClient CLIs wherever possible, close gaps in it"},{"line_number":18,"context_line":"where necessary to enable this, and call out specific and intentional uses of the"},{"line_number":19,"context_line":"python clients as transitional until support can be added."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"1f621f24_73b6408d","line":17,"range":{"start_line":16,"start_character":73,"end_line":17,"end_character":66},"updated":"2020-11-17 21:44:33.000000000","message":"Unless the OSC supports all user actions described in the project documentation, this is going to bring about the situation decried in lines 9-11, namely, frustration at having to use multiple CLIs.  So (1) I\u0027m not sure this is an improvement over using a single python-x client throughout the documentation, but if that\u0027s what the TC wants, OK.  (2) \"wherever possible\" is too broad and should be loosened to something like \"wherever it makes sense to do so\".  What I mean is, if the docs are describing a workflow where you do X and then do Y to verify the action, and X is only available in a python-x CLI but Y is available in OSC, surely we don\u0027t want to say that the documentation must use OSC for Y because it\u0027s possible?  Or maybe we do ... in any case, that\u0027s a situation that is guaranteed to arise, and it would be good to know what the thinking of the TC is here.","commit_id":"8995cb2810a8b9fea9ac945fde99288426767f16"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"ef1a2bfcb3122aab8f8f9c8d877c45e053dbcb9f","unresolved":false,"context_lines":[{"line_number":13,"context_line":"In order to better support the user experience and encourage adoption by new"},{"line_number":14,"context_line":"users of the unified client, we will have a twofold policy."},{"line_number":15,"context_line":""},{"line_number":16,"context_line":"Firstly, going forward, OpenStack services should focus on ensuring that all"},{"line_number":17,"context_line":"user-oriented documents use OpenStackClient CLIs wherever possible, close gaps in it"},{"line_number":18,"context_line":"where necessary to enable this, and call out specific and intentional uses of the"},{"line_number":19,"context_line":"python clients as transitional until support can be added."},{"line_number":20,"context_line":""}],"source_content_type":"text/x-rst","patch_set":6,"id":"fffc6b78_727db86d","line":17,"range":{"start_line":16,"start_character":73,"end_line":17,"end_character":66},"in_reply_to":"1f621f24_73b6408d","updated":"2020-11-18 18:57:21.000000000","message":"I think in your example we want to get X implemented in the OSC so that we can say use the OSC for all of it. And if you can\u0027t do X in the OSC mention that this will change in the docs so that users know there is progress in the direction of unification.","commit_id":"8995cb2810a8b9fea9ac945fde99288426767f16"},{"author":{"_account_id":13995,"name":"Nate Johnston","email":"nate.johnston@redhat.com","username":"natejohnston"},"change_message_id":"b0ac98008c2849394bc79729f89c4c6409f1928a","unresolved":false,"context_lines":[{"line_number":19,"context_line":"python clients as transitional until support can be added."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Secondly, in an effort to champion our own tooling for the purposes of highlighting any"},{"line_number":22,"context_line":"existing unrealized gaps in user workflows, anything in our upstream CI that interacts"},{"line_number":23,"context_line":"with an openstack service should use the OpenStackClient wherever possible. When"},{"line_number":24,"context_line":"this is not possible, a bug should be filed highlighting the feature gap."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"This resolution is not going to dictate a completion date, but is to ensure that we make"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1f621f24_94fa4bba","line":23,"range":{"start_line":22,"start_character":44,"end_line":23,"end_character":74},"updated":"2020-11-09 20:44:18.000000000","message":"I would amend this to say \"anything that interacts with an OpenStack service from the command line\" for clarity.  \n\nOr alternatively you could say \"use the OpenStackClient or the OpenStack SDK\" because heat, rally, etc. are used in some upstream CI jobs and they use SDK.","commit_id":"8995cb2810a8b9fea9ac945fde99288426767f16"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"ef1a2bfcb3122aab8f8f9c8d877c45e053dbcb9f","unresolved":false,"context_lines":[{"line_number":19,"context_line":"python clients as transitional until support can be added."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Secondly, in an effort to champion our own tooling for the purposes of highlighting any"},{"line_number":22,"context_line":"existing unrealized gaps in user workflows, anything in our upstream CI that interacts"},{"line_number":23,"context_line":"with an openstack service should use the OpenStackClient wherever possible. When"},{"line_number":24,"context_line":"this is not possible, a bug should be filed highlighting the feature gap."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"This resolution is not going to dictate a completion date, but is to ensure that we make"}],"source_content_type":"text/x-rst","patch_set":6,"id":"fffc6b78_b2960094","line":23,"range":{"start_line":22,"start_character":44,"end_line":23,"end_character":74},"in_reply_to":"1f621f24_94fa4bba","updated":"2020-11-18 18:57:21.000000000","message":"Done","commit_id":"8995cb2810a8b9fea9ac945fde99288426767f16"},{"author":{"_account_id":5314,"name":"Brian Rosmaita","email":"rosmaita.fossdev@gmail.com","username":"brian-rosmaita"},"change_message_id":"1bae08a7eb77988d1f0aaedefc0c3d50689750da","unresolved":false,"context_lines":[{"line_number":19,"context_line":"python clients as transitional until support can be added."},{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Secondly, in an effort to champion our own tooling for the purposes of highlighting any"},{"line_number":22,"context_line":"existing unrealized gaps in user workflows, anything in our upstream CI that interacts"},{"line_number":23,"context_line":"with an openstack service should use the OpenStackClient wherever possible. When"},{"line_number":24,"context_line":"this is not possible, a bug should be filed highlighting the feature gap."},{"line_number":25,"context_line":""},{"line_number":26,"context_line":"This resolution is not going to dictate a completion date, but is to ensure that we make"}],"source_content_type":"text/x-rst","patch_set":6,"id":"1f621f24_f32c10ae","line":23,"range":{"start_line":22,"start_character":44,"end_line":23,"end_character":74},"in_reply_to":"1f621f24_94fa4bba","updated":"2020-11-17 21:44:33.000000000","message":"Nate has a good point.  Tempest explicitly writes its own clients to interact directly with the service APIs, and I don\u0027t think the goal here is to force a tempest rewrite to use CLI calls or the SDK?  It would be good to be more specific about what the TC has in mind here.","commit_id":"8995cb2810a8b9fea9ac945fde99288426767f16"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"a55f043658318d1923f53291c530a885941fa4af","unresolved":false,"context_lines":[{"line_number":6,"context_line":"together in a single shell with a uniform command structure[0]."},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":9,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":10,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":11,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"}],"source_content_type":"text/x-rst","patch_set":7,"id":"fffc6b78_8d60f234","line":10,"range":{"start_line":9,"start_character":71,"end_line":10,"end_character":18},"updated":"2020-11-19 14:15:08.000000000","message":"listed above?\n\nOr all OpenStack services?\nI see that you clarified the projects above because of a review comment - I\u0027m looking for further clarity here if this means that *each* openstack service project with a REST API must have support in the OpenStackSDK and OpenStackClient, or is it just the projects that were tightly integrated?","commit_id":"871c8bd60eb280cbb6c8853a072c5d905d1aa464"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"e3f5db107e8627afae987ec429ae5546711c10d4","unresolved":false,"context_lines":[{"line_number":6,"context_line":"together in a single shell with a uniform command structure[0]."},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":9,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":10,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":11,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"}],"source_content_type":"text/x-rst","patch_set":7,"id":"1db744fc_aef8a441","line":10,"range":{"start_line":9,"start_character":71,"end_line":10,"end_character":18},"in_reply_to":"0e24f805_2cd66af0","updated":"2020-12-03 19:20:37.000000000","message":"yeah, +1. I mentioned it in previous PS comment also. I think we should have a clear direction in this resolution on below things to have all of us in same page.\n\n1. what is proposal for python-*client are we going to remove them completely or keep as python binding and plugins for osc\n\n2. are we recommending all projects to have python binding in openstacksdk. does all mean all services or core services/integrated and have plugins like Goutham mentioned.","commit_id":"871c8bd60eb280cbb6c8853a072c5d905d1aa464"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"97e1fb0f223eae5640018ca5b5b13434d0ecf00a","unresolved":true,"context_lines":[{"line_number":6,"context_line":"together in a single shell with a uniform command structure[0]."},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":9,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":10,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":11,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"}],"source_content_type":"text/x-rst","patch_set":7,"id":"542985c1_b86e0db1","line":10,"range":{"start_line":9,"start_character":71,"end_line":10,"end_character":18},"in_reply_to":"1db744fc_aef8a441","updated":"2020-12-10 22:52:26.000000000","message":"When we discussed this resolution at the PTG and I said I would write it, it was supposed to be pretty high level. \n\nI don\u0027t think *I* should be the only TC member to decide on the answers to your questions Goutham and Ghanshyam :) I would like to hear opinions from other TC members. I can see us keeping the clients as python bindings, but I think that it would be better to have them in the sdk? I\u0027m sure there are pros and cons to each approach. The SDK team might have better insight there.","commit_id":"871c8bd60eb280cbb6c8853a072c5d905d1aa464"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"4cd5d9db7c35be7f1e39e4d0b0c2dc93255b13f0","unresolved":false,"context_lines":[{"line_number":6,"context_line":"together in a single shell with a uniform command structure[0]."},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":9,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":10,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":11,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"}],"source_content_type":"text/x-rst","patch_set":7,"id":"0e24f805_2cd66af0","line":10,"range":{"start_line":9,"start_character":71,"end_line":10,"end_character":18},"in_reply_to":"fffc6b78_8d60f234","updated":"2020-12-03 14:43:21.000000000","message":"@Kendall?","commit_id":"871c8bd60eb280cbb6c8853a072c5d905d1aa464"},{"author":{"_account_id":9003,"name":"Tom Barron","email":"tpb@dyncloud.net","username":"tbarron"},"change_message_id":"1b831ba1f9d4596517f7d1ec09979f764aaa971e","unresolved":true,"context_lines":[{"line_number":8,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":9,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":10,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":11,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":14,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":7,"id":"62d1efbb_6c192105","line":11,"range":{"start_line":11,"start_character":37,"end_line":11,"end_character":77},"updated":"2020-12-08 17:33:52.000000000","message":"Don\u0027t we want to allow for use of project specific clients for standalone use cases even if we want to have completeness on the OSC side and use OSC examples for focus in regular OpenStack user-facing documents.  Deprecation of this sort would not require total project specific client *removal*, right?","commit_id":"871c8bd60eb280cbb6c8853a072c5d905d1aa464"},{"author":{"_account_id":9003,"name":"Tom Barron","email":"tpb@dyncloud.net","username":"tbarron"},"change_message_id":"b8f26948110414b5ce5facbeab2d992d9a286361","unresolved":true,"context_lines":[{"line_number":8,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":9,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":10,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":11,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":14,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":7,"id":"f7190d4a_fd69df9d","line":11,"range":{"start_line":11,"start_character":37,"end_line":11,"end_character":77},"in_reply_to":"2b12237d_5c756548","updated":"2020-12-08 18:27:46.000000000","message":"Sure, if the uninstalled project commands are hidden in that case as well.\n\nMy main point is that making OSC complete and performant and using it in all the regular public user docs, etc. is one thing.  That enables elimination of individual projects\u0027 clients but does not require it, and in the case of projects that admit of the (proposed) \u0027suports-standalone\u0027 tag there may be a reason not to eliminate the standalone clients.  Clearly it is desirable in such cases to use a different \"skin\" on common code.","commit_id":"871c8bd60eb280cbb6c8853a072c5d905d1aa464"},{"author":{"_account_id":9003,"name":"Tom Barron","email":"tpb@dyncloud.net","username":"tbarron"},"change_message_id":"adbe8907b7c71d07244cbc1fe79705936be73004","unresolved":true,"context_lines":[{"line_number":8,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":9,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":10,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":11,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":14,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":7,"id":"d813ccac_f976e2f0","line":11,"range":{"start_line":11,"start_character":37,"end_line":11,"end_character":77},"in_reply_to":"3f10e8a6_ec145b1a","updated":"2020-12-10 23:26:08.000000000","message":"I\u0027m certainly not advocating maintenance of two parallel implementations, just pointing out that a lot can be achieved by getting OSC feature complete and performant and aligning projects with that goal without additionally getting them to commit to removal of their own clients.  If cinder or ironic or manila want to have their own client for standalone and figure a way to do that with a plugin to osc or use of sdk by both in a way that doesn\u0027t increase tech debt, etc., then why would the TC go on record in this resolution as saying they are against that?\n\nI applaud the overall effort, not intending in any way to be negative about that.","commit_id":"871c8bd60eb280cbb6c8853a072c5d905d1aa464"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"14e05041998afff975c4f5f9eeae02f79c7ee627","unresolved":true,"context_lines":[{"line_number":8,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":9,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":10,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":11,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":14,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":7,"id":"f5758c06_3f6d8d4d","line":11,"range":{"start_line":11,"start_character":37,"end_line":11,"end_character":77},"in_reply_to":"62d1efbb_6c192105","updated":"2020-12-08 17:39:42.000000000","message":"that is good point, we need to think of standalone case too.","commit_id":"871c8bd60eb280cbb6c8853a072c5d905d1aa464"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"76a33d2cab02f25f9d628408e57946712bdff258","unresolved":true,"context_lines":[{"line_number":8,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":9,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":10,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":11,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":14,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":7,"id":"2b12237d_5c756548","line":11,"range":{"start_line":11,"start_character":37,"end_line":11,"end_character":77},"in_reply_to":"f5758c06_3f6d8d4d","updated":"2020-12-08 18:03:11.000000000","message":"+1, maintaining two parallel CLI implementations will be a drain eventually - it is necessary in the meantime when we\u0027re trying to gain parity. \n\nBUT, when we\u0027re done integrating everything into the OpenStackCLI... for projects like cinder, manila, ironic or xyz when deployed without the rest of openstack, we could perhaps encourage out an out-of-the-box solution to substitute the word \"openstack\" with the project name perhaps?","commit_id":"871c8bd60eb280cbb6c8853a072c5d905d1aa464"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"97e1fb0f223eae5640018ca5b5b13434d0ecf00a","unresolved":true,"context_lines":[{"line_number":8,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":9,"context_line":"client instead of continuing to maintain the individual python clients for each of the"},{"line_number":10,"context_line":"OpenStack services and the best way to approach reaching parity between the two"},{"line_number":11,"context_line":"client approaches so as to deprecate and remove the project specific clients."},{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":14,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"}],"source_content_type":"text/x-rst","patch_set":7,"id":"3f10e8a6_ec145b1a","line":11,"range":{"start_line":11,"start_character":37,"end_line":11,"end_character":77},"in_reply_to":"f7190d4a_fd69df9d","updated":"2020-12-10 22:52:26.000000000","message":"I don\u0027t think we want to maintain two parallel implementations. That seems like a good way to rapidly increase tech debt and always be fighting to keep parity. I think if a project has the \u0027supports-standalone\u0027 tag, we need to handle them differently than those that don\u0027t. Those that don\u0027t, I think should not have their own clients and everything should live in the OpenStackSDK and OpenStackCLI.","commit_id":"871c8bd60eb280cbb6c8853a072c5d905d1aa464"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"a55f043658318d1923f53291c530a885941fa4af","unresolved":false,"context_lines":[{"line_number":12,"context_line":""},{"line_number":13,"context_line":"Having to use more than one client in a basic workflow is a very confusing and"},{"line_number":14,"context_line":"frustrating experience for OpenStack users. Using a combination of clients makes"},{"line_number":15,"context_line":"OpenStack feel disjointed and overly complex."},{"line_number":16,"context_line":""},{"line_number":17,"context_line":"In order to better support the user experience and encourage adoption by new"},{"line_number":18,"context_line":"users of the unified client, we will have a twofold policy."}],"source_content_type":"text/x-rst","patch_set":7,"id":"fffc6b78_ed541e57","line":15,"range":{"start_line":15,"start_character":44,"end_line":15,"end_character":45},"updated":"2020-11-19 14:15:08.000000000","message":"+1","commit_id":"871c8bd60eb280cbb6c8853a072c5d905d1aa464"},{"author":{"_account_id":16643,"name":"Goutham Pacha Ravi","email":"gouthampravi@gmail.com","username":"gouthamr"},"change_message_id":"34ff4f05f9c9c5afcef9637316439fce9ed62fcc","unresolved":true,"context_lines":[{"line_number":2,"context_line":"2020-10-28 OpenStackClient TC Policy"},{"line_number":3,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":4,"context_line":"OpenStackClient (aka OSC) is a command-line client for OpenStack that brings the"},{"line_number":5,"context_line":"command set for Compute, Identity, Image, Object Storage and Block Storage APIs"},{"line_number":6,"context_line":"together in a single shell with a uniform command structure[0]."},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"For several releases now, there has been much debate about unifying on a single"}],"source_content_type":"text/x-rst","patch_set":8,"id":"bb562068_c4280887","line":5,"range":{"start_line":5,"start_character":16,"end_line":5,"end_character":79},"updated":"2021-01-08 20:13:53.000000000","message":"\"OpenStack service APIs (such as those for Compute, Deployment, Identity, Image, Networking and Storage orchestration)\"","commit_id":"42034b4bf34883c007290edb03ba80b638f7df59"},{"author":{"_account_id":841,"name":"Akihiro Motoki","email":"amotoki@gmail.com","username":"amotoki"},"change_message_id":"1de447062bfa2690e20cdcdf5d6911cbabda881c","unresolved":true,"context_lines":[{"line_number":3,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":4,"context_line":"OpenStackClient (aka OSC) is a command-line client for OpenStack that brings the"},{"line_number":5,"context_line":"command set for Compute, Identity, Image, Object Storage and Block Storage APIs"},{"line_number":6,"context_line":"together in a single shell with a uniform command structure[0]."},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":9,"context_line":"client and the best way to approach reaching parity between the OSC and project"}],"source_content_type":"text/x-rst","patch_set":8,"id":"68e31af8_fcd93dd4","line":6,"updated":"2021-01-08 09:38:27.000000000","message":"I am a bit sad as \"Network\" is not covered here :p","commit_id":"42034b4bf34883c007290edb03ba80b638f7df59"},{"author":{"_account_id":16708,"name":"Kendall Nelson","display_name":"Kendall (diablo_rojo)","email":"kennelson11@gmail.com","username":"kjnelson"},"change_message_id":"fbb346cc137082e644b93a8d1280c6b1948e2305","unresolved":true,"context_lines":[{"line_number":3,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":4,"context_line":"OpenStackClient (aka OSC) is a command-line client for OpenStack that brings the"},{"line_number":5,"context_line":"command set for Compute, Identity, Image, Object Storage and Block Storage APIs"},{"line_number":6,"context_line":"together in a single shell with a uniform command structure[0]."},{"line_number":7,"context_line":""},{"line_number":8,"context_line":"For several releases now, there has been much debate about unifying on a single"},{"line_number":9,"context_line":"client and the best way to approach reaching parity between the OSC and project"}],"source_content_type":"text/x-rst","patch_set":8,"id":"9e0269a2_fa1f6361","line":6,"in_reply_to":"68e31af8_fcd93dd4","updated":"2021-01-08 17:19:50.000000000","message":"I think I copied it directly from the OSC description in projects.yaml in this repo so you can blame it on my reference :)","commit_id":"42034b4bf34883c007290edb03ba80b638f7df59"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"07474ad522bb48b068d403272a0619d58e54027c","unresolved":true,"context_lines":[{"line_number":24,"context_line":"Secondly, in an effort to champion our own tooling for the purposes of highlighting any"},{"line_number":25,"context_line":"existing unrealized gaps in user workflows, anything that interacts with an OpenStack"},{"line_number":26,"context_line":"service from the command line should use the OpenStackClient or OpenStackSDK wherever"},{"line_number":27,"context_line":"possible. When this is not possible, a bug should be filed highlighting the feature gap."},{"line_number":28,"context_line":""},{"line_number":29,"context_line":"This resolution is not going to dictate a completion date, but is to ensure that we make"},{"line_number":30,"context_line":"continuous forward progress in that direction."}],"source_content_type":"text/x-rst","patch_set":8,"id":"32ea390e_81c395f2","line":27,"updated":"2021-01-13 15:37:03.000000000","message":"I think the intent was to make this second requirement one of our CI stuff, right? Meaning.. \"anything in our CI should use osc whenever possible, because dogfood.\" Is this intentionally more vague or did the CI terminology just get lost in the edits?","commit_id":"42034b4bf34883c007290edb03ba80b638f7df59"},{"author":{"_account_id":27900,"name":"Artem Goncharov","email":"artem.goncharov@gmail.com","username":"gtema"},"change_message_id":"c89f1bdc953f02a6ce4a4cb6796a193aa3bdab7a","unresolved":true,"context_lines":[{"line_number":2,"context_line":"2020-10-28 OpenStackClient TC Policy"},{"line_number":3,"context_line":"\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d"},{"line_number":4,"context_line":"OpenStackClient (aka OSC) is a command-line client for OpenStack that"},{"line_number":5,"context_line":"brings the command set for Compute, Identity, Image, Object Storage"},{"line_number":6,"context_line":"and Block Storage APIs together in a single shell with a uniform"},{"line_number":7,"context_line":"command structure[0]."},{"line_number":8,"context_line":""}],"source_content_type":"text/x-rst","patch_set":10,"id":"a51b46a3_aba2a5d2","line":5,"updated":"2021-01-14 18:05:50.000000000","message":"Ough, we actually missed Network (from main services)","commit_id":"d39a32de5461f4463cd52b944fb0c1ec043d2121"}]}