On Thu, Sep 3, 2020 at 9:05 AM Belmiro Moreira <moreira.belmiro.email.lists@gmail.com> wrote:
Hi everyone, thank you for all your comments. However, I don't think we have reached any conclusion.
It would be great if the SDK/openstackclient team and the different projects that raised some concerns can collaborate and move forward. Personally, I believe that the current situation is a very bad user experience.
Let us know how the TC can help.
Can we start by agreeing (or can the TC just top-down mandate?) an end state we want to get to? The way I've understood it and see it, what we're aiming for is: A. osc is user-facing CLI shell around sdk B. sdk is the only official client library for interacting with the OpenStack REST APIs I've been working with those assumptions for [1] and addressing point B, leaving point A to the osc team. If we take B to be true, patches like [2] would get blocked and redirected to the SDK for the API logic, with only the CLI parts in the osc. That doesn't seem to be the case, so I don't know what to think anymore. [1] https://review.opendev.org/#/q/status:open+project:openstack/openstacksdk+br... [2] https://review.opendev.org/#/c/675304/
cheers, Belmiro
On Fri, Aug 14, 2020 at 3:08 PM Sean McGinnis <sean.mcginnis@gmx.com> wrote:
And if it's to provide one CLI that rules them all, the individual projects (well, Cinder, anyway) can't stop adding functionality to cinderclient CLI until the openstackclient CLI has feature parity. At least now, you can use one CLI to do all cinder-related stuff. If we stop cinderclient CLI development, then you'll need to use openstackclient for some things (old features + the latest features) and the cinderclient for all the in between features, which doesn't seem like progress to me. And in reality, I don't think Cinder can even drop cinderclient even if we get feature parity. We have python-brick-cinderclient-ext that is used in conjunction with python-cinderclient for some standalone use cases.