OSC future (formerly [glance] Different checksum between CLI and curl)

Albert Braden Albert.Braden at synopsys.com
Tue Mar 3 17:07:55 UTC 2020


Sean, thank you for explaining this. I think I get it now.

-----Original Message-----
From: Sean Mooney <smooney at redhat.com> 
Sent: Monday, March 2, 2020 10:51 AM
To: Albert Braden <albertb at synopsys.com>; openstack-discuss <openstack-discuss at lists.openstack.org>
Subject: Re: OSC future (formerly [glance] Different checksum between CLI and curl)

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.



More information about the openstack-discuss mailing list