Folks, this is the *wrong* topic to discuss it. PS (basking in offtop): Thanks, Dmitry, I was looking for such a doc for jslib. -yoctozepto wt., 3 mar 2020 o 14:38 Dmitry Tantsur <dtantsur@redhat.com> napisał(a):
On Mon, Mar 2, 2020 at 8:46 PM Clark Boylan <cboylan@sapwetik.org> wrote:
On Mon, Mar 2, 2020, at 11:01 AM, Dmitry Tantsur wrote:
On Mon, Mar 2, 2020 at 5:37 PM Sean Mooney <smooney@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. >
Do we have proper microversion support then? This is a blocker for cinder.
The ironic team has been successfully hacking around the absence of a native microversion support for a while. We use ironicclient instead of openstacksdk, which makes things harder. If you use openstacksdk, it's easier to teach it microversions. In any case, I can provide some guidance if you'd like to.
Dmitry
On Mon, 2020-03-02 at 16:49 +0100, Dmitry Tantsur wrote: that is also problematic. by harcking around it it gives the ironic command a different behavior to the rest of osc. osc does support microverions it just does not support automatic versin negociation which is what you are hacking in.
Right, and it's a hard requirement for the CLI to be remotely usable.
i do agree that it would be nice to have support for version negociation where by you could do somehting like --os-compute-api-version=auto to opt in to it but automatic microverions detetion does make it harder to do help text generation unless you make "openstack --cloud=my-cloud --os-compute-api-version=auto help server create" call out to keystone get the nova endpoint and then lookup its max microversion when you render the help text.
The "auto" must be a default. This is what the users expect: the CLI just working. Defaulting to anything else does them a huge disservice (been there, done that).
As a user I strongly disagree. I don't want an API to magically start acting differently because the cloud side has upgraded. Those changes are opaque to me and I shouldn't need to know about them. Instead I should be able to opt into using new features when I know I need them. This is easily achieved by setting the desired microversion when you know you need it.
We're talking about CLI, not API. I agree with you when it comes to calling code, but CLI must just work. This is how all CLI in the world work: you either get a behavior or you get a clear failure. It's the other way around: if you want to fix the feature set, and you know what you're doing, you can set a specific version in your environment.
And, Clark, you and I are not mere users even if we use our CLI regularly. Draw the border here: a regular user is someone who doesn't know what a microversion even IS, to say nothing about a way to find the required microversion for a feature. These are the users I've dealt with and they have all been frustrated by using microversions explicitly.
For a probably clearer explanation let me refer you to the API SIG specification that covers how to expose microversions: https://specs.openstack.org/openstack/api-sig/guidelines/sdk-exposing-microv... (see specifically about high-level SDKs).
Dmitry
with that said if adding --os-image-api-version=auto was enough to get the glance team to fully adopt osc then i think that would be better then partioning the community between osc and legacy client. osc should behave consistently for all projects however so adding negocaiton for ironic and not for other services is not a good thing imo but i guess you were able to do that as ironic is integrated as a plugin correct?
Yep. We could not wait for OSC to implement it because the CLI is borderline unusable without this negotiation in place. I don't recall what prevented us from updating OSC, but I think there was a reason, probably not entirely technical.
Dmitry