From glance prospective we also didn't have any bandwidth to work on adding

Hi All, Thank you for making this different thread, OSC is not up to date with the current glance features and neither it has shown any interest in doing so. these support to OSC. There is some major feature gap between current OSC and Glance and that's the reason why glance does not recommend to use OSC. 1. Support for new image import workflow 2. Support for hidden images 3. Support for multihash 4. Support for multiple stores If anyone is interested to take up this work it will be great. Thanks & Best Regards, Abhishek Kekane On Tue, Mar 3, 2020 at 12:24 AM Sean Mooney <smooney@redhat.com> wrote:

...

As an openstack operator I was pretty ecstatic to hear that the assortment of clients would be replaced by a single client. I would be disappointed to find that a component would not integrate and would continue to use a separate client. This would be a step backward IMO.

The discussion about microversions goes over my head, but I would hope to see the developers get together and solve the issue and continue working toward integration. just to summerisie it in a non technical way.

On Mon, 2020-03-02 at 18:05 +0000, Albert Braden wrote: the project specific cli had a convention where the client would ask the api what the newest micoverion it supported and defualt to that if the clinet suported it. that meant that the same command executed against two different clouds with different versions of openstakc deploy could have different behavior and different responces. so from an interoperablity point of view that is not great but from a usablity point of view the fact enduser dont have to care about microverions and the client would try to do the right thing made some things much simpler.

the unifeid client (osc) chose to priorities interoperablity by defaulting to the oldest micorverions, so for nova that would be 2.0/2.1 meaning that if you execute the same command on two different cloud with different version of nova it will behave the same but if you want to use a feature intoduced in a later micorverion you have to explcitly request that via --os-compute-api-version or set that as a env var or in you cloud.yaml

so really the difference is that osc requires the end user to be explictl about what micoversion to use and therefor be explict about the behavior of the api they expect (this is what we expect application that use the the api should do) where as the project client tried to just work and use the latest microverion which mostly workd excpet where we remove a feature in a later micorverions. for example we removed the force option on some move operation in nova because allowing forcing caused many harder to fix issues. i dont thnk the nova clinet would cap at the latest micorvierion that allowed forcing. so the poject client genreally did not guarantee that a command would work without specifcing a new micorverison it just that we remove things a hell of a lot less often then we add them.

so as an end user that is the main difference between using osc vs glance clinet other then the fact i belive there is a bunch of stuff you can do with glance client that is missing in osc. parity is a spereate disucssion but it is vaild concern.

...

From: Radosław Piliszek <radoslaw.piliszek@gmail.com> Sent: Monday, March 2, 2020 9:07 AM To: openstack-discuss <openstack-discuss@lists.openstack.org> Subject: Re: [glance] Different checksum between CLI and curl

Folks,

sorry to interrupt but I think we have diverged a bit too much from the subject. Only last Gaetan message is on topic here. Please switch to new subject to discuss OSC future.

-yoctozepto

pon., 2 mar 2020 o 18:03 Tim Bell <tim.bell@cern.ch> napisał(a):

...

On 2 Mar 2020, at 16:49, Dmitry Tantsur <dtantsur@redhat.com> wrote:

Hi,

On Mon, Mar 2, 2020 at 4:29 PM Luigi Toscano <ltoscano@redhat.com>

wrote:

...

...

On Monday, 2 March 2020 10:54:03 CET Mark Goddard wrote:

...

On Mon, 2 Mar 2020 at 06:28, Abhishek Kekane <akekane@redhat.com>

wrote:

...

...

...

Hi Gaëtan,

Glance team doesn't recommend to use OSC anymore. I will recommend you to check the same behaviour using python-glanceclient.

That's not cool - everyone has switched to OSC. It's also the first time I've heard of it.

From the end user perspective, we’ve had positive feedback on the convergence to OSC from our cloud consumers.

There has been great progress with Manila to get shares included (

https://urldefense.proofpoint.com/v2/url?u=https-3A__review.opendev.org_-23_c_642222_26_&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=XrJBXYlVPpvOXkMqGPz6KucRW_ils95ZMrEmlTflPm8&m=gfnHFJM7fXXAlOxyUenF0xGqH3gNiec3LxN-Gd5Ey-o&s=SYi8yPy9Dz0CgrkT5P6rTzs3141Gj4K9zO4Ht3GTYAk&e=

...

) and it would be a pity if we’re asking our end users to understand all of the different project names and inconsistent options/arguments/syntax.

We had hoped for a project goal to get everyone aligned on OSC but

-----Original Message----- there was not consensus on this, I’d still

...

...

encourage it to simplify the experience for OpenStack cloud consumers.

Tim

Hi Artem, Thanks for sharing the update. The decision was collectively taken during last cycle by glance team, as we don't have enough people/resources to work on this front. I will be more than happy to change this if anyone comes forward and bridge the gaps. Thanks & Best Regards, Abhishek Kekane On Tue, Mar 3, 2020 at 11:40 AM Artem Goncharov <artem.goncharov@gmail.com> wrote:

On Tue, 3 Mar 2020, 06:08 Abhishek Kekane, <akekane@redhat.com> wrote:

...

Hi All,

Thank you for making this different thread,

OSC is not up to date with the current glance features and neither it has shown any interest in doing so. From glance prospective we also didn't have any bandwidth to work on adding these support to OSC.

That's honestly not true this days

...

There is some major feature gap between current OSC and Glance and that's the reason why glance does not recommend to use OSC.

That's still not reason to say please don't use it anymore.

1. Support for new image import workflow

...

Partially implemented by me and I continue working on that

2. Support for hidden images

...

Implemented

3. Support for multihash

...

4. Support for multiple stores

...

I am relying on OSC and especially for image service trying to bring it in a more useful state, thus fixing huge parts in SDK.

...

If anyone is interested to take up this work it will be great.

Thanks & Best Regards,

Abhishek Kekane

On Tue, Mar 3, 2020 at 12:24 AM Sean Mooney <smooney@redhat.com> wrote:

...

...

As an openstack operator I was pretty ecstatic to hear that the assortment of clients would be replaced by a single client. I would be disappointed to find that a component would not integrate and would continue to use a separate client. This would be a step backward IMO.

The discussion about microversions goes over my head, but I would hope to see the developers get together and solve the issue and continue working toward integration. just to summerisie it in a non technical way.

On Mon, 2020-03-02 at 18:05 +0000, Albert Braden wrote: the project specific cli had a convention where the client would ask the api what the newest micoverion it supported and defualt to that if the clinet suported it. that meant that the same command executed against two different clouds with different versions of openstakc deploy could have different behavior and different responces. so from an interoperablity point of view that is not great but from a usablity point of view the fact enduser dont have to care about microverions and the client would try to do the right thing made some things much simpler.

the unifeid client (osc) chose to priorities interoperablity by defaulting to the oldest micorverions, so for nova that would be 2.0/2.1 meaning that if you execute the same command on two different cloud with different version of nova it will behave the same but if you want to use a feature intoduced in a later micorverion you have to explcitly request that via --os-compute-api-version or set that as a env var or in you cloud.yaml

so really the difference is that osc requires the end user to be explictl about what micoversion to use and therefor be explict about the behavior of the api they expect (this is what we expect application that use the the api should do) where as the project client tried to just work and use the latest microverion which mostly workd excpet where we remove a feature in a later micorverions. for example we removed the force option on some move operation in nova because allowing forcing caused many harder to fix issues. i dont thnk the nova clinet would cap at the latest micorvierion that allowed forcing. so the poject client genreally did not guarantee that a command would work without specifcing a new micorverison it just that we remove things a hell of a lot less often then we add them.

so as an end user that is the main difference between using osc vs glance clinet other then the fact i belive there is a bunch of stuff you can do with glance client that is missing in osc. parity is a spereate disucssion but it is vaild concern.

...

From: Radosław Piliszek <radoslaw.piliszek@gmail.com> Sent: Monday, March 2, 2020 9:07 AM To: openstack-discuss <openstack-discuss@lists.openstack.org> Subject: Re: [glance] Different checksum between CLI and curl

Folks,

sorry to interrupt but I think we have diverged a bit too much from

...

Only last Gaetan message is on topic here. Please switch to new subject to discuss OSC future.

-yoctozepto

pon., 2 mar 2020 o 18:03 Tim Bell <tim.bell@cern.ch> napisał(a):

...

On 2 Mar 2020, at 16:49, Dmitry Tantsur <dtantsur@redhat.com> wrote:

Hi,

On Mon, Mar 2, 2020 at 4:29 PM Luigi Toscano <ltoscano@redhat.com>

wrote:

...

...

On Monday, 2 March 2020 10:54:03 CET Mark Goddard wrote: > On Mon, 2 Mar 2020 at 06:28, Abhishek Kekane <akekane@redhat.com>

wrote:

...

> > Hi Gaëtan, > > > > Glance team doesn't recommend to use OSC anymore. > > I will recommend you to check the same behaviour using > > python-glanceclient. > > That's not cool - everyone has switched to OSC. It's also the first > time I've heard of it. >

From the end user perspective, we’ve had positive feedback on the convergence to OSC from our cloud consumers.

There has been great progress with Manila to get shares included (

https://urldefense.proofpoint.com/v2/url?u=https-3A__review.opendev.org_-23_c_642222_26_&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=XrJBXYlVPpvOXkMqGPz6KucRW_ils95ZMrEmlTflPm8&m=gfnHFJM7fXXAlOxyUenF0xGqH3gNiec3LxN-Gd5Ey-o&s=SYi8yPy9Dz0CgrkT5P6rTzs3141Gj4K9zO4Ht3GTYAk&e=

...

) and it would be a pity if we’re asking our end users to understand all of the different project names and inconsistent options/arguments/syntax.

We had hoped for a project goal to get everyone aligned on OSC but

-----Original Message----- the subject. there was not consensus on this, I’d still

...

...

encourage it to simplify the experience for OpenStack cloud consumers.

Tim

On 3/3/20 11:28 AM, Albert Braden wrote:

Am I understanding correctly that the Openstack community decided to focus on the unified client, and to deprecate the individual clients, and that the Glance team did not agree with this decision, and that the Glance team is now having a pissing match with the rest of the community, and is unilaterally deciding to continue developing the Glance client and refusing to work on the unified client, or is something different going on? I would ask everyone involved to remember that we operators are down here, and the yellow rain falling on our heads does not smell very good.

I definitely would not characterize it that way. With trying not to put too much personal bias into it, here's what I would say the situation is: - Some part of the community has said OSC should be the only CLI and that individual CLIs should go away - Glance is a very small team with very, very limited resources - The OSC team is a very small team with very, very limited resources - CLI capabilities need to be exposed for Glance changes and the easiest way to get them out for the is by updating the Glance CLI - No one from the OSC team has been able to proactively help to make sure these changes make it into the OSC client (see bullet 3) - There exists a sizable functionality gap between per-project CLIs and what OSC provides, and although a few people have done a lot of great work to close that gap, there is still a lot to be done and does not appear the gap will close at any point in the near future based on the current trends

On 3 Mar 2020, at 19:20, Albert Braden <Albert.Braden@synopsys.com> wrote:

Sean, thank you for clarifying that.

Was my understanding that the community decided to focus on the unified client incorrect? Is the unified/individual client debate still a matter of controversy? Is it possible that the unified client will be deprecated in favor of individual clients after more discussion? I haven’t looked at any of the individual clients since 2018 (except for osc-placement which is kind of a special case), because I thought they were all going away and could be safely ignored until they did, and I haven’t included any information about the individual clients in the documentation that I write for our users, and if they ask I have been telling them to not use the individual clients. Do I need to start looking at individual clients again, and telling our users to use them in some cases?

I remember a forum discussion where a community goal was proposed to focus on OSC rather than individual project CLIs (I think Matt and I were proposers). There were concerns on the effort to do this and that it would potentially be multi-cycle. My experience in discussion with the CERN user community and other OpenStack operators is that OSC is felt to be the right solution for the end user facing parts of the cloud (admin commands could be another discussion if necessary). Experienced admin operators can remember that glance looks after images and nova looks after instances. Our average user can get very confused, especially given that OSC supports additional options for authentication (such as Kerberos and Certificates along with clouds.yaml) so users need to re-authenticate with a different openrc to work on their project. While I understand there are limited resources all round, I would prefer that we focus on adding new project functions to OSC which will eventually lead to feature parity. Attracting ‘drive-by’ contributions from operations staff for OSC work (it's more likely to be achieved if it makes the operations work less e.g. save on special end user documentation by contributing code). This is demonstrated from the CERN team contribution to the OSC ‘coe' and ‘share' functionality along with lots of random OSC updates as listed hat https://www.stackalytics.com/?company=cern&metric=commits&module=python-openstackclient <https://www.stackalytics.com/?company=cern&metric=commits&module=python-openstackclient>) BTW, I also would vote for =auto as the default. Tim

We are on Rocky now but I expect that we will upgrade as necessary to stay on supported versions.

From: Sean McGinnis <sean.mcginnis@gmx.com> Sent: Tuesday, March 3, 2020 9:50 AM To: openstack-discuss@lists.openstack.org Subject: Re: OSC future (formerly [glance] Different checksum between CLI and curl)

On 3/3/20 11:28 AM, Albert Braden wrote: Am I understanding correctly that the Openstack community decided to focus on the unified client, and to deprecate the individual clients, and that the Glance team did not agree with this decision, and that the Glance team is now having a pissing match with the rest of the community, and is unilaterally deciding to continue developing the Glance client and refusing to work on the unified client, or is something different going on? I would ask everyone involved to remember that we operators are down here, and the yellow rain falling on our heads does not smell very good. I definitely would not characterize it that way.

With trying not to put too much personal bias into it, here's what I would say the situation is:

- Some part of the community has said OSC should be the only CLI and that individual CLIs should go away - Glance is a very small team with very, very limited resources - The OSC team is a very small team with very, very limited resources - CLI capabilities need to be exposed for Glance changes and the easiest way to get them out for the is by updating the Glance CLI - No one from the OSC team has been able to proactively help to make sure these changes make it into the OSC client (see bullet 3) - There exists a sizable functionality gap between per-project CLIs and what OSC provides, and although a few people have done a lot of great work to close that gap, there is still a lot to be done and does not appear the gap will close at any point in the near future based on the current trends

---- On Tue, 03 Mar 2020 13:00:35 -0600 Tim Bell <tim.bell@cern.ch> wrote ----

On 3 Mar 2020, at 19:55, Tim Bell <tim.bell@cern.ch> wrote:

On 3 Mar 2020, at 19:20, Albert Braden <Albert.Braden@synopsys.com> wrote: Sean, thank you for clarifying that.

Was my understanding that the community decided to focus on the unified client incorrect? Is the unified/individual client debate still a matter of controversy? Is it possible that the unified client will be deprecated in favor of individual clients after more discussion? I haven’t looked at any of the individual clients since 2018 (except for osc-placement which is kind of a special case), because I thought they were all going away and could be safely ignored until they did, and I haven’t included any information about the individual clients in the documentation that I write for our users, and if they ask I have been telling them to not use the individual clients. Do I need to start looking at individual clients again, and telling our users to use them in some cases?

I remember a forum discussion where a community goal was proposed to focus on OSC rather than individual project CLIs (I think Matt and I were proposers). There were concerns on the effort to do this and that it would potentially be multi-cycle. BTW, I found the etherpad from Berlin (https://etherpad.openstack.org/p/BER-t-series-goals) and the associated mailing list discussion at http://lists.openstack.org/pipermail/openstack-dev/2018-September/135107.htm...

Yeah, we are in process of selecting the Victoria cycle community-wide goal and this can be good candidate. I agree with the idea/requirement of a multi-cycle goal. Another option is to build a pop-up team for the Victoria cycle to start burning down the keys issues/work. For both ways (either goal or pop-up team), we need some set of people to drive it. If anyone would like to volunteer for this, we can start discussing the details. [1] http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012866.... -gmann

My experience in discussion with the CERN user community and other OpenStack operators is that OSC is felt to be the right solution for the end user facing parts of the cloud (admin commands could be another discussion if necessary). Experienced admin operators can remember that glance looks after images and nova looks after instances. Our average user can get very confused, especially given that OSC supports additional options for authentication (such as Kerberos and Certificates along with clouds.yaml) so users need to re-authenticate with a different openrc to work on their project. While I understand there are limited resources all round, I would prefer that we focus on adding new project functions to OSC which will eventually lead to feature parity. Attracting ‘drive-by’ contributions from operations staff for OSC work (it's more likely to be achieved if it makes the operations work less e.g. save on special end user documentation by contributing code). This is demonstrated from the CERN team contribution to the OSC ‘coe' and ‘share' functionality along with lots of random OSC updates as listed hat https://www.stackalytics.com/?company=cern&metric=commits&module=python-openstackclient) BTW, I also would vote for =auto as the default. Tim We are on Rocky now but I expect that we will upgrade as necessary to stay on supported versions.

From: Sean McGinnis <sean.mcginnis@gmx.com> Sent: Tuesday, March 3, 2020 9:50 AM To: openstack-discuss@lists.openstack.org Subject: Re: OSC future (formerly [glance] Different checksum between CLI and curl)

On 3/3/20 11:28 AM, Albert Braden wrote: Am I understanding correctly that the Openstack community decided to focus on the unified client, and to deprecate the individual clients, and that the Glance team did not agree with this decision, and that the Glance team is now having a pissing match with the rest of the community, and is unilaterally deciding to continue developing the Glance client and refusing to work on the unified client, or is something different going on? I would ask everyone involved to remember that we operators are down here, and the yellow rain falling on our heads does not smell very good. I definitely would not characterize it that way. With trying not to put too much personal bias into it, here's what I would say the situation is: - Some part of the community has said OSC should be the only CLI and that individual CLIs should go away - Glance is a very small team with very, very limited resources - The OSC team is a very small team with very, very limited resources - CLI capabilities need to be exposed for Glance changes and the easiest way to get them out for the is by updating the Glance CLI - No one from the OSC team has been able to proactively help to make sure these changes make it into the OSC client (see bullet 3) - There exists a sizable functionality gap between per-project CLIs and what OSC provides, and although a few people have done a lot of great work to close that gap, there is still a lot to be done and does not appear the gap will close at any point in the near future based on the current trends

---- On Wed, 04 Mar 2020 03:57:52 -0600 Mark Goddard <mark@stackhpc.com> wrote ----

On Wed, 4 Mar 2020 at 01:16, Ghanshyam Mann <gmann@ghanshyammann.com> wrote:

...

---- On Tue, 03 Mar 2020 13:00:35 -0600 Tim Bell <tim.bell@cern.ch> wrote ----

...

On 3 Mar 2020, at 19:55, Tim Bell <tim.bell@cern.ch> wrote:

On 3 Mar 2020, at 19:20, Albert Braden <Albert.Braden@synopsys.com> wrote: Sean, thank you for clarifying that.

Was my understanding that the community decided to focus on the unified client incorrect? Is the unified/individual client debate still a matter of controversy? Is it possible that the unified client will be deprecated in favor of individual clients after more discussion? I haven’t looked at any of the individual clients since 2018 (except for osc-placement which is kind of a special case), because I thought they were all going away and could be safely ignored until they did, and I haven’t included any information about the individual clients in the documentation that I write for our users, and if they ask I have been telling them to not use the individual clients. Do I need to start looking at individual clients again, and telling our users to use them in some cases?

I remember a forum discussion where a community goal was proposed to focus on OSC rather than individual project CLIs (I think Matt and I were proposers). There were concerns on the effort to do this and that it would potentially be multi-cycle. BTW, I found the etherpad from Berlin (https://etherpad.openstack.org/p/BER-t-series-goals) and the associated mailing list discussion at http://lists.openstack.org/pipermail/openstack-dev/2018-September/135107.htm...

Yeah, we are in process of selecting the Victoria cycle community-wide goal and this can be good candidate. I agree with the idea/requirement of a multi-cycle goal. Another option is to build a pop-up team for the Victoria cycle to start burning down the keys issues/work. For both ways (either goal or pop-up team), we need some set of people to drive it. If anyone would like to volunteer for this, we can start discussing the details.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012866....

-gmann

This seems like quite an important issue for OpenStack usability. Clearly there are resourcing issues within the glance team (and possibly also some personal preferences) that have prevented OSC gaining feature parity with the glance client. Having all of the core projects able to recommend using OSC seems to me like it should be quite a high priority - more so than having support for every project out there. Would cross-project goal effort be better spent swarming on filling these gaps first? Do we have any mechanisms to help drive that? I know we have the help most-wanted list.

That is a good idea to first target big projects. We can finish this for nova, glance, cinder, keystone, glance, swift at first. Apart from Upstream Opportunity (help-most-wanted list) [2], one better way is pop-up team [1]. For that, we need a set of people from these projects or any developer to start working. Also, we can add this as the upstream opportunity for 2020 and see if we get any help. [1] https://governance.openstack.org/tc/reference/popup-teams.html [2] https://governance.openstack.org/tc/reference/upstream-investment-opportunit... -gmann

...

...

My experience in discussion with the CERN user community and other OpenStack operators is that OSC is felt to be the right solution for the end user facing parts of the cloud (admin commands could be another discussion if necessary). Experienced admin operators can remember that glance looks after images and nova looks after instances. Our average user can get very confused, especially given that OSC supports additional options for authentication (such as Kerberos and Certificates along with clouds.yaml) so users need to re-authenticate with a different openrc to work on their project. While I understand there are limited resources all round, I would prefer that we focus on adding new project functions to OSC which will eventually lead to feature parity. Attracting ‘drive-by’ contributions from operations staff for OSC work (it's more likely to be achieved if it makes the operations work less e.g. save on special end user documentation by contributing code). This is demonstrated from the CERN team contribution to the OSC ‘coe' and ‘share' functionality along with lots of random OSC updates as listed hat https://www.stackalytics.com/?company=cern&metric=commits&module=python-openstackclient) BTW, I also would vote for =auto as the default. Tim We are on Rocky now but I expect that we will upgrade as necessary to stay on supported versions.

From: Sean McGinnis <sean.mcginnis@gmx.com> Sent: Tuesday, March 3, 2020 9:50 AM To: openstack-discuss@lists.openstack.org Subject: Re: OSC future (formerly [glance] Different checksum between CLI and curl)

On 3/3/20 11:28 AM, Albert Braden wrote: Am I understanding correctly that the Openstack community decided to focus on the unified client, and to deprecate the individual clients, and that the Glance team did not agree with this decision, and that the Glance team is now having a pissing match with the rest of the community, and is unilaterally deciding to continue developing the Glance client and refusing to work on the unified client, or is something different going on? I would ask everyone involved to remember that we operators are down here, and the yellow rain falling on our heads does not smell very good. I definitely would not characterize it that way. With trying not to put too much personal bias into it, here's what I would say the situation is: - Some part of the community has said OSC should be the only CLI and that individual CLIs should go away - Glance is a very small team with very, very limited resources - The OSC team is a very small team with very, very limited resources - CLI capabilities need to be exposed for Glance changes and the easiest way to get them out for the is by updating the Glance CLI - No one from the OSC team has been able to proactively help to make sure these changes make it into the OSC client (see bullet 3) - There exists a sizable functionality gap between per-project CLIs and what OSC provides, and although a few people have done a lot of great work to close that gap, there is still a lot to be done and does not appear the gap will close at any point in the near future based on the current trends

Well, part of maintaining feature parity is that the features should be added to the OSC by the project team at the time they're made -- you're already doing the work to add them to your own client, so instead, do the same amount of work but add them in OSC instead! It doesn't seem incredibly onerous to me. If the OSC plugin for your project IS the official client, then there's no duplication of effort. I think saying "someone else had better implement our features in a timely fashion" is a bit irresponsible. Though, this is coming from working on a project where we aren't used to being included as a "core piece" and having any work done for us, ever... Also, things are also definitely moving in a better direction now with the probable addition of project team liasons as cores in SDK/OSC, which should alleviate a lot of the issues around "response time" on reviews, when you do put in the effort to add features yourself. --Adam On Fri, Mar 6, 2020, 00:15 Erno Kuvaja <ekuvaja@redhat.com> wrote:

On Wed, Mar 4, 2020 at 1:19 AM Ghanshyam Mann <gmann@ghanshyammann.com> wrote:

...

---- On Tue, 03 Mar 2020 13:00:35 -0600 Tim Bell <tim.bell@cern.ch> wrote ----

...

On 3 Mar 2020, at 19:55, Tim Bell <tim.bell@cern.ch> wrote:

On 3 Mar 2020, at 19:20, Albert Braden <Albert.Braden@synopsys.com>

...

Sean, thank you for clarifying that.

Was my understanding that the community decided to focus on the unified client incorrect? Is the unified/individual client debate still a matter of controversy? Is it possible that the unified client will be deprecated in favor of individual clients after more discussion? I haven’t looked at any of the individual clients since 2018 (except for osc-placement which is kind of a special case), because I thought they were all going away and could be safely ignored until they did, and I haven’t included any information about the individual clients in the documentation

wrote: that I write for our users, and if they ask I have been telling them to not use the individual clients. Do I need to start looking at individual clients again, and telling our users to use them in some cases?

...

I remember a forum discussion where a community goal was proposed to

focus on OSC rather than individual project CLIs (I think Matt and I were proposers). There were concerns on the effort to do this and that it would potentially be multi-cycle.

...

BTW, I found the etherpad from Berlin ( https://etherpad.openstack.org/p/BER-t-series-goals) and the associated mailing list discussion at http://lists.openstack.org/pipermail/openstack-dev/2018-September/135107.htm...

Yeah, we are in process of selecting the Victoria cycle community-wide goal and this can be good candidate. I agree with the idea/requirement of a multi-cycle goal. Another option is to build a pop-up team for the Victoria cycle to start burning down the keys issues/work. For both ways (either goal or pop-up team), we need some set of people to drive it. If anyone would like to volunteer for this, we can start discussing the details.

[1] http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012866....

-gmann

Yeah, lets propose this as community goal again as it worked so well last time. ಠ_ಠ

I think your most help wanted list/pop-up team is much more realistic approach. Lets see if there is enough interest to actually make it happen. What comes to our previous experience with Glance and moving to endorse osc, I think I'm not alone stating that we can discuss this again after osc has kept feature parity (and I mean to current release, not feature parity 2 years ago kind of thing) and actively addressed raised issues at least for a couple of cycles. Obviously if you/your users wants to use it meanwhile, that your call. If we cannot get that level of commitment, how do we expect to support this long term?

I'm not willing to put our users through that misery again as it happened last time as long as I'm core in this project.

- jokke

...

...

My experience in discussion with the CERN user community and other

...

While I understand there are limited resources all round, I would

OpenStack operators is that OSC is felt to be the right solution for the end user facing parts of the cloud (admin commands could be another discussion if necessary). Experienced admin operators can remember that glance looks after images and nova looks after instances. Our average user can get very confused, especially given that OSC supports additional options for authentication (such as Kerberos and Certificates along with clouds.yaml) so users need to re-authenticate with a different openrc to work on their project. prefer that we focus on adding new project functions to OSC which will eventually lead to feature parity.

...

Attracting ‘drive-by’ contributions from operations staff for OSC work (it's more likely to be achieved if it makes the operations work less e.g. save on special end user documentation by contributing code). This is demonstrated from the CERN team contribution to the OSC ‘coe' and ‘share' functionality along with lots of random OSC updates as listed hat https://www.stackalytics.com/?company=cern&metric=commits&module=python-openstackclient)

...

BTW, I also would vote for =auto as the default. Tim We are on Rocky now but I expect that we will upgrade as necessary to stay on supported versions.

From: Sean McGinnis <sean.mcginnis@gmx.com> Sent: Tuesday, March 3, 2020 9:50 AM To: openstack-discuss@lists.openstack.org Subject: Re: OSC future (formerly [glance] Different checksum between CLI and curl)

On 3/3/20 11:28 AM, Albert Braden wrote: Am I understanding correctly that the Openstack community decided to focus on the unified client, and to deprecate the individual clients, and that the Glance team did not agree with this decision, and that the Glance team is now having a pissing match with the rest of the community, and is unilaterally deciding to continue developing the Glance client and refusing to work on the unified client, or is something different going on? I would ask everyone involved to remember that we operators are down here, and the yellow rain falling on our heads does not smell very good. I definitely would not characterize it that way. With trying not to put too much personal bias into it, here's what I would say the situation is: - Some part of the community has said OSC should be the only CLI and that individual CLIs should go away - Glance is a very small team with very, very limited resources - The OSC team is a very small team with very, very limited resources - CLI capabilities need to be exposed for Glance changes and the easiest way to get them out for the is by updating the Glance CLI - No one from the OSC team has been able to proactively help to make sure these changes make it into the OSC client (see bullet 3) - There exists a sizable functionality gap between per-project CLIs and what OSC provides, and although a few people have done a lot of great work to close that gap, there is still a lot to be done and does not appear the gap will close at any point in the near future based on the current trends

On Fri, 6 Mar 2020, 00:03 melanie witt, <melwittt@gmail.com> wrote:

On 3/5/20 12:11, Adam Harwell wrote:

...

Well, part of maintaining feature parity is that the features should be added to the OSC by the project team at the time they're made -- you're already doing the work to add them to your own client, so instead, do the same amount of work but add them in OSC instead! It doesn't seem incredibly onerous to me. If the OSC plugin for your project IS the official client, then there's no duplication of effort. I think saying "someone else had better implement our features in a timely fashion" is a bit irresponsible. Though, this is coming from working on a project where we aren't used to being included as a "core piece" and having any work done for us, ever...

I think this is the key point regarding the lack of feature parity in OSC for some projects.

If you are a new-enough project to have begun your CLI as an OSC plugin (examples: ironic client, placement client, and more) then adding a feature to the client is one shot. You add support in the plugin and you're done.

If you are an older project (examples: nova client, glance client) then you have a two-step process for adding a feature to OSC. For older projects, OSC imports the legacy clients and calls their python bindings to make the API calls. So for nova, if you want to add a feature to the client, you have to add it to the legacy nova client. This is required. Then, to add it to OSC you have to add it to OSC and have OSC call the newly added legacy binding for the feature. This is [technically] optional. This is why parity is missing.

Hopefully in some days for glance this will not be necessary anymore, since there is a patch waiting to be merged, which switches OSC to SDK for Glance and removes glanceclient from dependencies. For neutron it is not required since long time. But still, what you say was real way to implement things, but it doesn't mean it is a correct or the easiest way. Instead if team once invests time to bring OSC Plugin, which bases on SDK in parity ... - the old client might be deprecated and you don't have this double efforts. The SDK/OSC team can not and should not try to catch all projects with their features each release - it is impossible (there are just 3 active cores in SDK now but hundreds of projects we might want to support). This team enables projects in a "unified technology stack" so that they become responsible for implementing all new features there.

It pains me a bit to write it ^ because you may be thinking, "what's so difficult about going the extra step to add a feature to OSC after adding it to nova client?" I don't know. Maybe people are too stressed and busy. If it's not "required", it gets deferred. Maybe people don't feel familiar enough with OSC to add the feature there as well. There could be a lot of different reasons.

So, not trying to make excuses here but just sharing my opinion on why adding features to OSC is not so simple for some projects.

It's not if you prioritize things not correctly and chooses complex direction. I'm laughing so loud, that this "storm" started just out of one question "OSC works correct, but curl not, so what am I doing wrong". It just one more time convinces me in some form of radicalisation of some projects against bringing things in order. Regards, Artem

Cheers, -melanie

...

Also, things are also definitely moving in a better direction now with the probable addition of project team liasons as cores in SDK/OSC, which should alleviate a lot of the issues around "response time" on reviews, when you do put in the effort to add features yourself.

--Adam

On Fri, Mar 6, 2020, 00:15 Erno Kuvaja <ekuvaja@redhat.com <mailto:ekuvaja@redhat.com>> wrote:

On Wed, Mar 4, 2020 at 1:19 AM Ghanshyam Mann <gmann@ghanshyammann.com <mailto:gmann@ghanshyammann.com>> wrote:

---- On Tue, 03 Mar 2020 13:00:35 -0600 Tim Bell <tim.bell@cern.ch <mailto:tim.bell@cern.ch>> wrote ---- > > > On 3 Mar 2020, at 19:55, Tim Bell <tim.bell@cern.ch <mailto:tim.bell@cern.ch>> wrote: > > > On 3 Mar 2020, at 19:20, Albert Braden <Albert.Braden@synopsys.com <mailto:Albert.Braden@synopsys.com>> wrote: > Sean, thank you for clarifying that. > > Was my understanding that the community decided to focus on the unified client incorrect? Is the unified/individual client debate still a matter of controversy? Is it possible that the unified client will be deprecated in favor of individual clients after more discussion? I haven’t looked at any of the individual clients since 2018 (except for osc-placement which is kind of a special case), because I thought they were all going away and could be safely ignored until they did, and I haven’t included any information about the individual clients in the documentation that I write for our users, and if they ask I have been telling them to not use the individual clients. Do I need to start looking at individual clients again, and telling our users to use them in some cases? > > > > I remember a forum discussion where a community goal was proposed to focus on OSC rather than individual project CLIs (I think Matt and I were proposers). There were concerns on the effort to do this and that it would potentially be multi-cycle. > BTW, I found the etherpad from Berlin (https://etherpad.openstack.org/p/BER-t-series-goals) and the associated mailing list discussion at

http://lists.openstack.org/pipermail/openstack-dev/2018-September/135107.htm...

...

Yeah, we are in process of selecting the Victoria cycle community-wide goal and this can be good candidate. I agree with the idea/requirement of a multi-cycle goal. Another option is to build a pop-up team for the Victoria cycle to start burning down the keys issues/work. For both ways (either goal or pop-up team), we need some set of people to drive it. If anyone would like to volunteer for this, we can start discussing the details.

[1]

http://lists.openstack.org/pipermail/openstack-discuss/2020-February/012866....

...

-gmann

Yeah, lets propose this as community goal again as it worked so well last time. |ಠ_ಠ|

I think your most help wanted list/pop-up team is much more realistic approach. Lets see if there is enough interest to actually make it happen. What comes to our previous experience with Glance and moving to endorse osc, I think I'm not alone stating that we can discuss this again after osc has kept feature parity (and I mean to current release, not feature parity 2 years ago kind of thing) and actively addressed raised issues at least for a couple of cycles. Obviously if you/your users wants to use it meanwhile, that your call. If we cannot get that level of commitment, how do we expect to support this long term?

I'm not willing to put our users through that misery again as it happened last time as long as I'm core in this project.

- jokke

> > My experience in discussion with the CERN user community and other OpenStack operators is that OSC is felt to be the right solution for the end user facing parts of the cloud (admin commands could be another discussion if necessary). Experienced admin operators can remember that glance looks after images and nova looks after instances. Our average user can get very confused, especially given that OSC supports additional options for authentication (such as Kerberos and Certificates along with clouds.yaml) so users need to re-authenticate with a different openrc to work on their project. > While I understand there are limited resources all round, I would prefer that we focus on adding new project functions to OSC which will eventually lead to feature parity. > Attracting ‘drive-by’ contributions from operations staff for OSC work (it's more likely to be achieved if it makes the operations work less e.g. save on special end user documentation by contributing code). This is demonstrated from the CERN team contribution to the OSC ‘coe' and ‘share' functionality along with lots of random OSC updates as listed hat

https://www.stackalytics.com/?company=cern&metric=commits&module=python-openstackclient )

...

> BTW, I also would vote for =auto as the default. > Tim > We are on Rocky now but I expect that we will upgrade as necessary to stay on supported versions. > > From: Sean McGinnis <sean.mcginnis@gmx.com <mailto:sean.mcginnis@gmx.com>> > Sent: Tuesday, March 3, 2020 9:50 AM > To: openstack-discuss@lists.openstack.org <mailto:openstack-discuss@lists.openstack.org> > Subject: Re: OSC future (formerly [glance] Different checksum between CLI and curl) > > On 3/3/20 11:28 AM, Albert Braden wrote: > Am I understanding correctly that the Openstack community decided to focus on the unified client, and to deprecate the individual clients, and that the Glance team did not agree with this decision, and that the Glance team is now having a pissing match with the rest of the community, and is unilaterally deciding to continue developing the Glance client and refusing to work on the unified client, or is something different going on? I would ask everyone involved to remember that we operators are down here, and the yellow rain falling on our heads does not smell very good. > I definitely would not characterize it that way. > With trying not to put too much personal bias into it, here's what I would say the situation is: > - Some part of the community has said OSC should be the only CLI and that individual CLIs should go away > - Glance is a very small team with very, very limited

resources

...

> - The OSC team is a very small team with very, very limited resources > - CLI capabilities need to be exposed for Glance changes and the easiest way to get them out for the is by updating the Glance CLI > - No one from the OSC team has been able to proactively help to make sure these changes make it into the OSC client (see bullet 3) > - There exists a sizable functionality gap between per-project CLIs and what OSC provides, and although a few people have done a lot of great work to close that gap, there is still a lot to be done and does not appear the gap will close at any point in the near future based on the current trends > > > > >

Thanks everyone for the helpful answers. I think I understand the situation now, and I know what to expect. I'll continue attempting to get signed up as a developer as time permits. Hopefully I can help fix some of the OSC issues. -----Original Message----- From: Monty Taylor <mordred@inaugust.com> Sent: Tuesday, March 3, 2020 12:13 PM To: Tim Bell <tim.bell@cern.ch> Cc: openstack-discuss@lists.openstack.org; Sean McGinnis <sean.mcginnis@gmx.com>; Albert Braden <albertb@synopsys.com> Subject: Re: OSC future (formerly [glance] Different checksum between CLI and curl)

On Mar 3, 2020, at 12:55 PM, Tim Bell <tim.bell@cern.ch> wrote:

...

On 3 Mar 2020, at 19:20, Albert Braden <Albert.Braden@synopsys.com> wrote:

Sean, thank you for clarifying that.

Was my understanding that the community decided to focus on the unified client incorrect? Is the unified/individual client debate still a matter of controversy? Is it possible that the unified client will be deprecated in favor of individual clients after more discussion? I haven’t looked at any of the individual clients since 2018 (except for osc-placement which is kind of a special case), because I thought they were all going away and could be safely ignored until they did, and I haven’t included any information about the individual clients in the documentation that I write for our users, and if they ask I have been telling them to not use the individual clients. Do I need to start looking at individual clients again, and telling our users to use them in some cases?

I remember a forum discussion where a community goal was proposed to focus on OSC rather than individual project CLIs (I think Matt and I were proposers). There were concerns on the effort to do this and that it would potentially be multi-cycle.

My experience in discussion with the CERN user community and other OpenStack operators is that OSC is felt to be the right solution for the end user facing parts of the cloud (admin commands could be another discussion if necessary). Experienced admin operators can remember that glance looks after images and nova looks after instances. Our average user can get very confused, especially given that OSC supports additional options for authentication (such as Kerberos and Certificates along with clouds.yaml) so users need to re-authenticate with a different openrc to work on their project.

While I understand there are limited resources all round, I would prefer that we focus on adding new project functions to OSC which will eventually lead to feature parity.

Attracting ‘drive-by’ contributions from operations staff for OSC work (it's more likely to be achieved if it makes the operations work less e.g. save on special end user documentation by contributing code). This is demonstrated from the CERN team contribution to the OSC ‘coe' and ‘share' functionality along with lots of random OSC updates as listed hat https://urldefense.proofpoint.com/v2/url?u=https-3A__www.stackalytics.com_-3Fcompany-3Dcern-26metric-3Dcommits-26module-3Dpython-2Dopenstackclient&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=XrJBXYlVPpvOXkMqGPz6KucRW_ils95ZMrEmlTflPm8&m=PXaDUXdLASc5aN6yB6-2EAZhPajJl-7Ue1eZOWhBS-s&s=r14Sy3wGjaak4CcfQegBje22E5rxQKgxMq_x9dXcDH0&e= )

We’ve been working in SDK also to empower more people directly by being a bit more liberal with core. I think it’s time to start applying this approach to OSC as well. It’s never going to work to require the OSC team to implement everything, but neither is it super awesome to completely decentralize as the plugin/entrypoints issues have shown. I think SDK has been happy with blessing service humans rather quickly.

BTW, I also would vote for =auto as the default

This is what the case will be as we move towards replacing more and more of OSC’s guts with SDK. But let me describe it slightly differently: The way this works in SDK is that there is ONE user interface, which wants to track the latest as best as it can. But we can’t just do “auto” - because microversions can introduce breaking changes, so we need to add support to SDK for the most recent microversion we’re aware of. Then SDK negotiates to find the best microversion that is understands, and it always uses that. SDK has the POV that an end-user should almost never need to care about a micro version - if a user cares they are either in nova-core, or we’ve done something wrong. Case in point is this: https://urldefense.proofpoint.com/v2/url?u=https-3A__opendev.org_openstack_openstacksdk_src_branch_master_openstack_compute_v2_server.py-23L457-2DL474&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=XrJBXYlVPpvOXkMqGPz6KucRW_ils95ZMrEmlTflPm8&m=PXaDUXdLASc5aN6yB6-2EAZhPajJl-7Ue1eZOWhBS-s&s=DIR_Qd19fwvb18RV_tqnnwOwFjffzojLOLIeE1oKLtU&e= The nova team rightfully changed the semantics of live migrate because of safety. Mriedem put together the logic to express what the appropriate behavior would be, given a set of inputs, across the range of versions so that a user can do things and they’ll work. The end result is a live_migrate call that works across versions as safely as it can. I mention all of this because getting this work done was one of the key things we wanted to get right before we started transitioning OSC in earnest. It’s there - it works, and it’s being used across nova and ironic. So - I hear what people want from OSC - they want a thing that behaves like auto does. We agree - and the mechanism that makes us able to do that _safely_ is things like the above.

Tim

...

We are on Rocky now but I expect that we will upgrade as necessary to stay on supported versions.

From: Sean McGinnis <sean.mcginnis@gmx.com> Sent: Tuesday, March 3, 2020 9:50 AM To: openstack-discuss@lists.openstack.org Subject: Re: OSC future (formerly [glance] Different checksum between CLI and curl)

On 3/3/20 11:28 AM, Albert Braden wrote: Am I understanding correctly that the Openstack community decided to focus on the unified client, and to deprecate the individual clients, and that the Glance team did not agree with this decision, and that the Glance team is now having a pissing match with the rest of the community, and is unilaterally deciding to continue developing the Glance client and refusing to work on the unified client, or is something different going on? I would ask everyone involved to remember that we operators are down here, and the yellow rain falling on our heads does not smell very good. I definitely would not characterize it that way.

With trying not to put too much personal bias into it, here's what I would say the situation is:

- Some part of the community has said OSC should be the only CLI and that individual CLIs should go away - Glance is a very small team with very, very limited resources - The OSC team is a very small team with very, very limited resources - CLI capabilities need to be exposed for Glance changes and the easiest way to get them out for the is by updating the Glance CLI - No one from the OSC team has been able to proactively help to make sure these changes make it into the OSC client (see bullet 3) - There exists a sizable functionality gap between per-project CLIs and what OSC provides, and although a few people have done a lot of great work to close that gap, there is still a lot to be done and does not appear the gap will close at any point in the near future based on the current trends

On 2020-03-03 18:20:59 +0000 (+0000), Albert Braden wrote: [...]

Was my understanding that the community decided to focus on the unified client incorrect? Is the unified/individual client debate still a matter of controversy?

I'll try to avoid revisiting points other folks have made in this thread, but feel obliged to highlight that "the community" does not possess a hive mind and the idea that it "decides" things is somewhat of a misunderstanding. I would characterize the focus on the unified client as a consensus choice, but that doesn't mean that everyone who has a stake in that choice is in agreement with the direction (and with a community the size of OpenStack's, it's unlikely everyone will ever agree unanimously on a topic).

Is it possible that the unified client will be deprecated in favor of individual clients after more discussion? [...]

Anything is possible. I don't personally consider that a likely outcome, but I don't think anyone has a crystal ball which can tell us that for certain.

Do I need to start looking at individual clients again, and telling our users to use them in some cases? [...]

I would take it as a sign to not ask the Glance contributors if you run into a problem using the unified OpenStack client or SDK, and try reproducing a problem with direct API interactions before reporting a bug against the Glance service (to avoid being told that they won't even look at it if your reproducer relies on OSC). -- Jeremy Stanley

Can shime in here that Puppet OpenStack has almost completely migrated to OSC since a pretty long time ago, including Glance. I think we only have some usage to the neutron CLI that needs to be replaced. (Even though I would like to talk directly to the APIs, but hey, Ruby isn't my strong suit). Best regards On 3/3/20 8:59 PM, Monty Taylor wrote:

...

On Mar 3, 2020, at 12:20 PM, Albert Braden <Albert.Braden@synopsys.com> wrote:

Sean, thank you for clarifying that.

Was my understanding that the community decided to focus on the unified client incorrect? Is the unified/individual client debate still a matter of controversy? Is it possible that the unified client will be deprecated in favor of individual clients after more discussion? Nope. Several of them even already don’t exist or are deprecated.

Additiontally, several surrounding tools have explicit policies to NEVER touch python-*client libraries. Specifically Ansible - but I believe Salt has also migrated to SDK - and then any app developer who wants to be able to sanely target multiple clouds uses SDK instead of python-*client.

So I can’t do anything about people preferring individual projects - but the unified stuff is DEFINITELY not getting deprecated or going away - quite simply because it cannot. And I hope that we can continue to convince more people of the power inherent in doing work to support their service in SDK/OSC instead of off in their own corner - but as I said, that I can’t do anything about.

...

I haven’t looked at any of the individual clients since 2018 (except for osc-placement which is kind of a special case), because I thought they were all going away and could be safely ignored until they did, and I haven’t included any information about the individual clients in the documentation that I write for our users, and if they ask I have been telling them to not use the individual clients. Do I need to start looking at individual clients again, and telling our users to use them in some cases?

We are on Rocky now but I expect that we will upgrade as necessary to stay on supported versions. From: Sean McGinnis <sean.mcginnis@gmx.com> Sent: Tuesday, March 3, 2020 9:50 AM To: openstack-discuss@lists.openstack.org Subject: Re: OSC future (formerly [glance] Different checksum between CLI and curl)

On 3/3/20 11:28 AM, Albert Braden wrote: Am I understanding correctly that the Openstack community decided to focus on the unified client, and to deprecate the individual clients, and that the Glance team did not agree with this decision, and that the Glance team is now having a pissing match with the rest of the community, and is unilaterally deciding to continue developing the Glance client and refusing to work on the unified client, or is something different going on? I would ask everyone involved to remember that we operators are down here, and the yellow rain falling on our heads does not smell very good. I definitely would not characterize it that way.

With trying not to put too much personal bias into it, here's what I would say the situation is:

- Some part of the community has said OSC should be the only CLI and that individual CLIs should go away - Glance is a very small team with very, very limited resources - The OSC team is a very small team with very, very limited resources - CLI capabilities need to be exposed for Glance changes and the easiest way to get them out for the is by updating the Glance CLI - No one from the OSC team has been able to proactively help to make sure these changes make it into the OSC client (see bullet 3) - There exists a sizable functionality gap between per-project CLIs and what OSC provides, and although a few people have done a lot of great work to close that gap, there is still a lot to be done and does not appear the gap will close at any point in the near future based on the current trends

Folks, I think we should clarify the problem we are discussing. The discussion started when the response to "there could be a bug in OSC" was "we are not recommending OSC". I don't feel like OSC lagging behind per-project-specific client in terms of features is a bad thing considering the workload. On the other hand, suddenly making OSC "not recommended" for a project already supported by / supporting OSC is a <<bad thing>>. (TM) I feel like there should be an official on how we are going to handle the clients situation and just document it. -yoctozepto wt., 3 mar 2020 o 19:11 Erno Kuvaja <ekuvaja@redhat.com> napisał(a):

On Tue, Mar 3, 2020 at 6:14 AM Artem Goncharov <artem.goncharov@gmail.com> wrote:

...

On Tue, 3 Mar 2020, 06:08 Abhishek Kekane, <akekane@redhat.com> wrote:

...

Hi All,

Thank you for making this different thread,

OSC is not up to date with the current glance features and neither it has shown any interest in doing so. From glance prospective we also didn't have any bandwidth to work on adding these support to OSC.

That's honestly not true this days

It's very much true that we do not have cycles for it. If you have found the time now after we've been complaining about the issues without any concrete actions for cycles, great for those who wants to use it.

...

...

There is some major feature gap between current OSC and Glance and that's the reason why glance does not recommend to use OSC.

That's still not reason to say please don't use it anymore.

But it very much is.

Tells quite a bit about the communication within the community that this is the first time we hear you actively working on those bits and making progress. Yet the osc is still lacking good year+ behind the feature parity and if the _demand_ is to use osc, "I'm just one person and have only so much time for this" is not good enough. Don't get me wrong, kudos to you to actually taking it on, but too little too late I guess.

If 95-100% of user issues with client gets resolved by "Have you tried to use the native glanceclient instead?" and the response is "Yes, it works, thanks." it very much tells that we should not be supporting and promoting the tooling that is not under our control and just does not work. (BTW we do encourage all those users to take their osc issues to the osc team to get fixed, yet we get these raised to us every so often.) This really got to the point where we had that very same discussion in multiple OpenStack summits in a row after the call was made that everything should move to osc and every time we got the same response "We know there are problems and we will look into it." After so many cycles and the gap growing not shrinking just got us to the point of moving forwards (or reverting back to something that actually works for our users). BTW we did announce this and it was discussed in PTG.

...

...

1. Support for new image import workflow

Partially implemented by me and I continue working on that

...

2. Support for hidden images

Implemented

...

3. Support for multihash

4. Support for multiple stores

I am relying on OSC and especially for image service trying to bring it in a more useful state, thus fixing huge parts in SDK.

That's great and obviously you have the freedom to choose the client you prefer to use. Just like we have a moral responsibility to our users to provide them reference client that is up to date, works and the issues raised gets attention.

This is all beyond the personal preference, which I get very mixed feedback of depending to whom I talk to. If I send the mail to the mailing list I get those same handful of people yelling right away how unified client is the only way to go and even thinking anything else is heresy. When I talk with people in the field, customers and users in the hallway tracks the message is much more mixed. The osc target audience prefers or just uses GUI instead, then there is a good portion of people who really don't care as they use some automation suite anyways, there is the old school guys who prefers a tool for a job as in the dedicated clients(I have to admit for disclaimer I belong to this group myself) and then there is a group of people who really don't care as long as the client they use every now and then just works. So honestly outside of those few voices in this mailing list I very rarely hear the demand of unified client and much more get the request to provide something that works, which was the major driver for our decision.

Harsh, absolutely; justified, I'd like to think so. And this is just my personal experience with Glance, we're in a blessed situation of not jumping into the microversions bandwagon which seems to be totally hidden can of worms from us in this topic.

For all the rest of you interested about the topic, next time you start demanding us to go to osc again, please put your money where your mouth is first and help those guys to deliver.

Best, Erno "jokke" Kuvaja

...

...

If anyone is interested to take up this work it will be great.

Thanks & Best Regards,

Abhishek Kekane

On Tue, Mar 3, 2020 at 12:24 AM Sean Mooney <smooney@redhat.com> wrote:

...

...

As an openstack operator I was pretty ecstatic to hear that the assortment of clients would be replaced by a single client. I would be disappointed to find that a component would not integrate and would continue to use a separate client. This would be a step backward IMO.

The discussion about microversions goes over my head, but I would hope to see the developers get together and solve the issue and continue working toward integration. just to summerisie it in a non technical way.

On Mon, 2020-03-02 at 18:05 +0000, Albert Braden wrote: the project specific cli had a convention where the client would ask the api what the newest micoverion it supported and defualt to that if the clinet suported it. that meant that the same command executed against two different clouds with different versions of openstakc deploy could have different behavior and different responces. so from an interoperablity point of view that is not great but from a usablity point of view the fact enduser dont have to care about microverions and the client would try to do the right thing made some things much simpler.

the unifeid client (osc) chose to priorities interoperablity by defaulting to the oldest micorverions, so for nova that would be 2.0/2.1 meaning that if you execute the same command on two different cloud with different version of nova it will behave the same but if you want to use a feature intoduced in a later micorverion you have to explcitly request that via --os-compute-api-version or set that as a env var or in you cloud.yaml

so really the difference is that osc requires the end user to be explictl about what micoversion to use and therefor be explict about the behavior of the api they expect (this is what we expect application that use the the api should do) where as the project client tried to just work and use the latest microverion which mostly workd excpet where we remove a feature in a later micorverions. for example we removed the force option on some move operation in nova because allowing forcing caused many harder to fix issues. i dont thnk the nova clinet would cap at the latest micorvierion that allowed forcing. so the poject client genreally did not guarantee that a command would work without specifcing a new micorverison it just that we remove things a hell of a lot less often then we add them.

so as an end user that is the main difference between using osc vs glance clinet other then the fact i belive there is a bunch of stuff you can do with glance client that is missing in osc. parity is a spereate disucssion but it is vaild concern.

-----Original Message-----

...

From: Radosław Piliszek <radoslaw.piliszek@gmail.com> Sent: Monday, March 2, 2020 9:07 AM To: openstack-discuss <openstack-discuss@lists.openstack.org> Subject: Re: [glance] Different checksum between CLI and curl

Folks,

sorry to interrupt but I think we have diverged a bit too much from the subject. Only last Gaetan message is on topic here. Please switch to new subject to discuss OSC future.

-yoctozepto

pon., 2 mar 2020 o 18:03 Tim Bell <tim.bell@cern.ch> napisał(a):

...

On 2 Mar 2020, at 16:49, Dmitry Tantsur <dtantsur@redhat.com> wrote:

Hi,

On Mon, Mar 2, 2020 at 4:29 PM Luigi Toscano <ltoscano@redhat.com> wrote: > > On Monday, 2 March 2020 10:54:03 CET Mark Goddard wrote: > > On Mon, 2 Mar 2020 at 06:28, Abhishek Kekane <akekane@redhat.com> wrote: > > > Hi Gaëtan, > > > > > > Glance team doesn't recommend to use OSC anymore. > > > I will recommend you to check the same behaviour using > > > python-glanceclient. > > > > That's not cool - everyone has switched to OSC. It's also the first > > time I've heard of it. > >

From the end user perspective, we’ve had positive feedback on the convergence to OSC from our cloud consumers.

There has been great progress with Manila to get shares included ( https://urldefense.proofpoint.com/v2/url?u=https-3A__review.opendev.org_-23_c_642222_26_&d=DwIFaQ&c=DPL6_X_6JkXFx7AXWqB0tg&r=XrJBXYlVPpvOXkMqGPz6KucRW_ils95ZMrEmlTflPm8&m=gfnHFJM7fXXAlOxyUenF0xGqH3gNiec3LxN-Gd5Ey-o&s=SYi8yPy9Dz0CgrkT5P6rTzs3141Gj4K9zO4Ht3GTYAk&e= ) and it would be a pity if we’re asking our end users to understand all of the different project names and inconsistent options/arguments/syntax.

We had hoped for a project goal to get everyone aligned on OSC but there was not consensus on this, I’d still encourage it to simplify the experience for OpenStack cloud consumers.

Tim