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 think I agree with the suggestion that a --os-compute-api-version=auto option might be a good solution to this conflict. Does anyone want to explain why this isn’t a good idea?
From: Abhishek Kekane <akekane@redhat.com>
Sent: Monday, March 2, 2020 10:18 PM
To: Artem Goncharov <artem.goncharov@gmail.com>
Cc: Sean Mooney <smooney@redhat.com>; Albert Braden <albertb@synopsys.com>; openstack-discuss <openstack-discuss@lists.openstack.org>
Subject: Re: OSC future (formerly [glance] Different checksum between CLI and curl)
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.
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
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.
On Mon, 2020-03-02 at 18:05 +0000, Albert Braden 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.
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
> >
> >
>
>