On Thu, 2020-08-13 at 10:30 -0400, Artom Lifshitz wrote:
> On Mon, Aug 10, 2020 at 4:40 AM Luigi Toscano <ltoscano@redhat.com> wrote:
> >
> > On Monday, 10 August 2020 10:26:24 CEST Radosław Piliszek wrote:
> > > On Mon, Aug 10, 2020 at 10:19 AM Belmiro Moreira <
> > >
> > > moreira.belmiro.email.lists@gmail.com> wrote:
> > > > Hi,
> > > > during the last PTG the TC discussed the problem of supporting different
> > > > clients (OpenStack Client - OSC vs python-*clients) [1].
> > > > Currently, we don't have feature parity between the OSC and the
> > > > python-*clients.
> > >
> > > Is it true of any client? I guess some are just OSC plugins 100%.
> > > Do we know which clients have this disparity?
> > > Personally, I encountered this with Glance the most and Cinder to some
> > > extent (but I believe over the course of action Cinder got all features I
> > > wanted from it in the OSC).
> >
> > As far as I know there is still a huge problem with microversion handling
> > which impacts some cinder features. It has been discussed in the past and
> > still present.
>
> Yeah, my understanding is that osc will never "properly" support
> microversions.
it does already properly support micorversion the issue is not everyone agrees
on what properly means. the behavior of the project clients was considered broken
by many. it has been poirpose that we explcity allow a way to opt in to the auto negociation
via a new "auto" sentaial value and i have also suggested that we should tag each comman with the minium
microversion that parmater or command requires and decault to that minium based on teh arges you passed.

both of those imporvement dont break the philosipy of providing stable cli behavior across cloud and would
imporve the ux. defaulting to the minium microversion needed for the arguments passed would solve most of the ux
issues and adding an auto sentical would resolve the rest while still keeping the correct microversion behvior it
already has.

the glance and cinder gaps are not really related to microverions by the way.
its just that no one has done the work and cinder an glance have not require contiuptors to update

osc as part of adding new features. nova has not required that either but there were some who worked on nova
that cared enough about osc to mention it in code review or submit patches themsevles. the glance team does
not really have the resouces to do that and the osc team does not have the resouce to maintain clis for all teams.

so over tiem as service poject added new feature the gaps have increase since there were not people tyring to keep it in
sync.

>  Openstacksdk is the future in that sense, and my
> understanding is that the osc team is "porting" osc to use the sdk.
> Given these two thing, when we (Nova) talked about this with the osc
> folks, we decided that rather than catch up osc to python-novaclient,
> we'd rather focus our efforts on the sdk.
well that is not entirly a good caraterisation. we want to catch up osc too
but the suggest was to support eveything in osc then it would be easier to add osc support
since it just has to call the sdk functions. we did not say we dont want to close the gaps in osc.

>  I've been slowly doing that
> [1], starting with the earlier Nova microversions. The eventual long
> term goal is for the Nova team to *only* support the sdk, and drop
> python-novaclient entirely, but that's a long time away.
>
> [1] https://review.opendev.org/#/q/status:open+project:openstack/openstacksdk+branch:master+topic:story/2007929
>
> >
> >
> > --
> > Luigi
> >
> >
> >
>
>