Open Stack

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200303/71ae441b/attachment-0001.html>