On Monday, 10 August 2020 10:26:24 CEST Radosław Piliszek wrote:

On Mon, Aug 10, 2020 at 10:19 AM Belmiro Moreira <

moreira.belmiro.email.lists@gmail.com> wrote:

...

Hi, during the last PTG the TC discussed the problem of supporting different clients (OpenStack Client - OSC vs python-*clients) [1]. Currently, we don't have feature parity between the OSC and the python-*clients.

Is it true of any client? I guess some are just OSC plugins 100%. Do we know which clients have this disparity? Personally, I encountered this with Glance the most and Cinder to some extent (but I believe over the course of action Cinder got all features I wanted from it in the OSC).

As far as I know there is still a huge problem with microversion handling which impacts some cinder features. It has been discussed in the past and still present. -- Luigi

On Thu, 2020-08-13 at 10:30 -0400, Artom Lifshitz wrote:

On Mon, Aug 10, 2020 at 4:40 AM Luigi Toscano <ltoscano@redhat.com> wrote:

...

On Monday, 10 August 2020 10:26:24 CEST Radosław Piliszek wrote:

...

On Mon, Aug 10, 2020 at 10:19 AM Belmiro Moreira <

moreira.belmiro.email.lists@gmail.com> wrote:

...

Hi, during the last PTG the TC discussed the problem of supporting different clients (OpenStack Client - OSC vs python-*clients) [1]. Currently, we don't have feature parity between the OSC and the python-*clients.

Is it true of any client? I guess some are just OSC plugins 100%. Do we know which clients have this disparity? Personally, I encountered this with Glance the most and Cinder to some extent (but I believe over the course of action Cinder got all features I wanted from it in the OSC).

As far as I know there is still a huge problem with microversion handling which impacts some cinder features. It has been discussed in the past and still present.

Yeah, my understanding is that osc will never "properly" support microversions. it does already properly support micorversion the issue is not everyone agrees on what properly means. the behavior of the project clients was considered broken by many. it has been poirpose that we explcity allow a way to opt in to the auto negociation via a new "auto" sentaial value and i have also suggested that we should tag each comman with the minium microversion that parmater or command requires and decault to that minium based on teh arges you passed.

both of those imporvement dont break the philosipy of providing stable cli behavior across cloud and would imporve the ux. defaulting to the minium microversion needed for the arguments passed would solve most of the ux issues and adding an auto sentical would resolve the rest while still keeping the correct microversion behvior it already has. the glance and cinder gaps are not really related to microverions by the way. its just that no one has done the work and cinder an glance have not require contiuptors to update osc as part of adding new features. nova has not required that either but there were some who worked on nova that cared enough about osc to mention it in code review or submit patches themsevles. the glance team does not really have the resouces to do that and the osc team does not have the resouce to maintain clis for all teams. so over tiem as service poject added new feature the gaps have increase since there were not people tyring to keep it in sync.

Openstacksdk is the future in that sense, and my understanding is that the osc team is "porting" osc to use the sdk. Given these two thing, when we (Nova) talked about this with the osc folks, we decided that rather than catch up osc to python-novaclient, we'd rather focus our efforts on the sdk. well that is not entirly a good caraterisation. we want to catch up osc too but the suggest was to support eveything in osc then it would be easier to add osc support since it just has to call the sdk functions. we did not say we dont want to close the gaps in osc.

I've been slowly doing that [1], starting with the earlier Nova microversions. The eventual long term goal is for the Nova team to *only* support the sdk, and drop python-novaclient entirely, but that's a long time away.

[1] https://review.opendev.org/#/q/status:open+project:openstack/openstacksdk+br...

...

-- Luigi

On Thu, Aug 13, 2020 at 4:46 PM Alan Bishop <abishop@redhat.com> wrote:

On Thu, Aug 13, 2020 at 8:27 AM Sean Mooney <smooney@redhat.com> wrote:

...

...

On Mon, Aug 10, 2020 at 4:40 AM Luigi Toscano <ltoscano@redhat.com> wrote:

...

On Monday, 10 August 2020 10:26:24 CEST Radosław Piliszek wrote:

...

On Mon, Aug 10, 2020 at 10:19 AM Belmiro Moreira <

moreira.belmiro.email.lists@gmail.com> wrote:

...

Hi, during the last PTG the TC discussed the problem of supporting

different

...

...

...

clients (OpenStack Client - OSC vs python-*clients) [1]. Currently, we don't have feature parity between the OSC and the python-*clients.

Is it true of any client? I guess some are just OSC plugins 100%. Do we know which clients have this disparity? Personally, I encountered this with Glance the most and Cinder to some extent (but I believe over the course of action Cinder got all features I wanted from it in the OSC).

As far as I know there is still a huge problem with microversion handling which impacts some cinder features. It has been discussed in the past and still present.

Yeah, my understanding is that osc will never "properly" support microversions. it does already properly support micorversion the issue is not everyone agrees on what properly means. the behavior of the project clients was considered broken by many. it has been poirpose that we explcity allow a way to opt in to

On Thu, 2020-08-13 at 10:30 -0400, Artom Lifshitz wrote: the auto negociation via a new "auto" sentaial value and i have also suggested that we should tag each comman with the minium microversion that parmater or command requires and decault to that minium based on teh arges you passed.

both of those imporvement dont break the philosipy of providing stable cli behavior across cloud and would imporve the ux. defaulting to the minium microversion needed for the arguments passed would solve most of the ux issues and adding an auto sentical would resolve the rest while still keeping the correct microversion behvior it already has.

the glance and cinder gaps are not really related to microverions by the way. its just that no one has done the work and cinder an glance have not require contiuptors to update

Updates to osc from cinder's side are pretty much stalled due to lack of support for microversions. A patch for that was rejected and we've had trouble getting an update on a viable path forward. See comment in https://review.opendev.org/590807.

Alan

...

osc as part of adding new features. nova has not required that either but there were some who worked on nova that cared enough about osc to mention it in code review or submit patches themsevles. the glance team does not really have the resouces to do that and the osc team does not have the resouce to maintain clis for all teams.

so over tiem as service poject added new feature the gaps have increase since there were not people tyring to keep it in sync.

...

Openstacksdk is the future in that sense, and my understanding is that the osc team is "porting" osc to use the sdk. Given these two thing, when we (Nova) talked about this with the osc folks, we decided that rather than catch up osc to python-novaclient, we'd rather focus our efforts on the sdk. well that is not entirly a good caraterisation. we want to catch up osc too but the suggest was to support eveything in osc then it would be easier to add osc support since it just has to call the sdk functions. we did not say we dont want to close the gaps in osc.

...

I've been slowly doing that [1], starting with the earlier Nova microversions. The eventual long term goal is for the Nova team to *only* support the sdk, and drop python-novaclient entirely, but that's a long time away.

[1] https://review.opendev.org/#/q/status:open+project:openstack/openstacksdk+br...

...

-- Luigi

So if I understand the whole picture correctly the situation has actually nothing to do with directly working OSC in favor of python-*client provided CLIs but actually moving everything to OSSDK so it can be supported and used by OSC to be used as default client for everything? As that seems to be a consensus that it's not enough to get the OSC to do the right thing if the client lib under the hood is still python-*client and specially if microversions. My question at this point is, do we (as a community) have enough bodies dedicated to OSSDK _and_ OSC to make this sustainable? I'm being sincere here as I have not been part of the development of either of those projects. But if my assumption above is correct, I think we should talk about these things with their real names rather than trying to mask this being just OSC vs python-*client CLI thing. - jokke

On Thu, Aug 13, 2020 at 12:45 PM Jeremy Stanley <fungi@yuggoth.org> wrote:

On 2020-08-13 17:27:16 +0100 (+0100), Erno Kuvaja wrote: [...]

...

My question at this point is, do we (as a community) have enough bodies dedicated to OSSDK _and_ OSC to make this sustainable? I'm being sincere here as I have not been part of the development of either of those projects. But if my assumption above is correct, I think we should talk about these things with their real names rather than trying to mask this being just OSC vs python-*client CLI thing.

Hopefully this doesn't come across as a glib response, but if people didn't have to maintain multiple CLIs and SDKs then maybe they would have enough time to collaborate on a universal CLI/SDK pair instead.

Agreed - but historically that's not what happened, so the question now is how to improve the situation. My understanding is that osc is effectively dead, except as a shell around the sdk, since that's where the future lies. So in my mind, efforts should be concentrated on two fronts: 1. Continue converting osc to use the sdk 2. Catch up the SDK This is a bit of a chicken and egg problem, because any gaps in sdk mean you can't convert osc to use those missing bits, but ideally any patches to osc that aren't sdk conversions would get blocked (though I have obviously absolutely no say in the matter, this is just wishful thinking). The project teams can work on 2 for their project (so like I've been slowly doing for Nova), the osc team can work on 1.

-- Jeremy Stanley

On 8/13/20 1:03 PM, Artom Lifshitz wrote:

On Thu, Aug 13, 2020 at 12:45 PM Jeremy Stanley <fungi@yuggoth.org> wrote:

...

On 2020-08-13 17:27:16 +0100 (+0100), Erno Kuvaja wrote: [...]

...

My question at this point is, do we (as a community) have enough bodies dedicated to OSSDK _and_ OSC to make this sustainable? I'm being sincere here as I have not been part of the development of either of those projects. But if my assumption above is correct, I think we should talk about these things with their real names rather than trying to mask this being just OSC vs python-*client CLI thing.

Hopefully this doesn't come across as a glib response, but if people didn't have to maintain multiple CLIs and SDKs then maybe they would have enough time to collaborate on a universal CLI/SDK pair instead.

Agreed - but historically that's not what happened, so the question now is how to improve the situation. My understanding is that osc is effectively dead, except as a shell around the sdk, since that's where the future lies. So in my mind, efforts should be concentrated on two fronts:

1. Continue converting osc to use the sdk 2. Catch up the SDK

My understanding is that the SDK is supposed to be an opinionated entry point to the APIs? Or am I thinking of some other project? I'm bringing this up because people say they want a single unified CLI, but when I've pushed operators about this, they want a CLI in Victoria that implements all the admin operations exposed by the Victorian-era APIs. A CLI built on an opinionated SDK is not going to do that. I could use some clarification on the goal and strategy here. If it's to provide a unified opinionated CLI, then I don't see how that helps us to eventually eliminate the project-specific CLIs. 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. Thus it would be helpful to have some clarification about the nature of the proposal we're discussing.

This is a bit of a chicken and egg problem, because any gaps in sdk mean you can't convert osc to use those missing bits, but ideally any patches to osc that aren't sdk conversions would get blocked (though I have obviously absolutely no say in the matter, this is just wishful thinking). The project teams can work on 2 for their project (so like I've been slowly doing for Nova), the osc team can work on 1. >

...

-- Jeremy Stanley

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.

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.

On Thu, 3 Sep 2020 at 16:45, Artem Goncharov <artem.goncharov@gmail.com> wrote:

...

On 3. Sep 2020, at 17:10, Artom Lifshitz <alifshit@redhat.com> wrote:

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.

From all the discussions we held over the time, yes, A is definitely our target (while there might be still special cases)

As SDK/OSC team we can say: B is true in a perfect world, but it is not a valid statement today. Somebody need to invest pretty huge effort in making this happen (I know this since I already invested in switching image part). During this time all the changes to OSC for things not based on SDK would need to be blocked. Amount of active people deep in the code of SDK/CLI is too small currently to handle this fast. On the other side, if nova team commits to do their patches to SDK first (what I see you guys are definitely doing, a great Thanks!) - we would be able to switch CLI for nova to SDK much easier. The more teams would be doing that, the easier would it be to clean OSC up.

Very unfortunately since last PTG there were only very minor activities in SDK/OSC team, but I would like to change this now (unfortunately there are still just 24 hours in the day). Let me see where I can find another few hours a day for repairing things and set a personal (or hopefully SDK team) target to move at least few nova resources onto CLI@SDK until next PTG. ;-)

I'm not working on this, and haven't been following it, but honestly given the current level of activity in OpenStack this sounds unlikely to happen. IMO from a user perspective, focussing on feature parity for OSC for all clients should be the priority, especially when teams like Glance say they would need multiple cycles with both clients maintaining parity in order to deprecate and drop their legacy client.

Regards, Another Artem

Hi Radosław, no, it's not true for every project. There are projects that have completely migrated to OSC (for example, Keystone). Other projects still have discrepancies (for example, Nova, Glance). Belmiro On Mon, Aug 10, 2020 at 10:26 AM Radosław Piliszek < radoslaw.piliszek@gmail.com> wrote:

On Mon, Aug 10, 2020 at 10:19 AM Belmiro Moreira < moreira.belmiro.email.lists@gmail.com> wrote:

...

Hi, during the last PTG the TC discussed the problem of supporting different clients (OpenStack Client - OSC vs python-*clients) [1]. Currently, we don't have feature parity between the OSC and the python-*clients.

Is it true of any client? I guess some are just OSC plugins 100%. Do we know which clients have this disparity? Personally, I encountered this with Glance the most and Cinder to some extent (but I believe over the course of action Cinder got all features I wanted from it in the OSC).

-yoctozepto

Hi, we would really appreciate your comments on this. Especially the OSC team and all the project teams that are facing issues migrating their clients.

Let us know, Belmiro

In Glance perspective we already stated that we're more than happy to try endorsing osc again once it has stabilized the Images API facing code and

On Thu, Aug 13, 2020 at 2:19 PM Belmiro Moreira < moreira.belmiro.email.lists@gmail.com> wrote: maintained feature parity for a few cycles. Just stopping developing python-glanceclient will only result in no up-to-date stable client for Images API developed under OpenStack Governance. I really don't think forcing to fork python-glanceclient to keep development going outside of OpenStack Governance will be the better solution here. - jokke On Mon, Aug 10, 2020 at 10:13 AM Belmiro Moreira <

moreira.belmiro.email.lists@gmail.com> wrote:

...

Hi, during the last PTG the TC discussed the problem of supporting different clients (OpenStack Client - OSC vs python-*clients) [1]. Currently, we don't have feature parity between the OSC and the python-*clients.

Different OpenStack projects invest in different clients. This can be a huge problem for users/ops. Depending on the projects deployed in their infrastructures, they need to use different clients for different tasks. It's confusing because of the partial implementation in the OSC.

There was also the proposal to enforce new functionality only in the SDK (and optionally the OSC) and not the project’s specific clients to stop increasing the disparity between the two.

We would like to understand first the problems and missing pieces that projects are facing to move into OSC and help to overcome them. Let us know.

Belmiro, on behalf of the TC

[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-June/015418.html