Open Stack

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 at gmail.com> 
> Sent: Monday, March 2, 2020 9:07 AM
> To: openstack-discuss <openstack-discuss at 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 at cern.ch> napisał(a):
> > 
> > 
> > 
> > On 2 Mar 2020, at 16:49, Dmitry Tantsur <dtantsur at redhat.com> wrote:
> > 
> > Hi,
> > 
> > On Mon, Mar 2, 2020 at 4:29 PM Luigi Toscano <ltoscano at 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 at 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
> > 
> > 
> 
>