Open Stack

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 at redhat.com> napisał(a):
>
>
>
> On Mon, Mar 2, 2020 at 8:46 PM Clark Boylan <cboylan at 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 at redhat.com> wrote:
>> > > On Mon, 2020-03-02 at 16:49 +0100, Dmitry Tantsur 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.
>> > >  > > >
>> > >  > >
>> > >  > > 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
>> > >  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-microversions.html (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
>>