Open Stack

On Thu, Aug 13, 2020 at 4:46 PM Alan Bishop <abishop at redhat.com> wrote:

>
>
> On Thu, Aug 13, 2020 at 8:27 AM Sean Mooney <smooney at redhat.com> wrote:
>
>> On Thu, 2020-08-13 at 10:30 -0400, Artom Lifshitz wrote:
>> > On Mon, Aug 10, 2020 at 4:40 AM Luigi Toscano <ltoscano at 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 at 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
>>
>
> Updates to osc from cinder's side are pretty much stalled due to lack of
> support for microversions. A patch for that was rejected and we've had
> trouble getting an update on a viable path forward. See comment in
> https://review.opendev.org/590807.
>
> Alan
>
>
>> 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
>> > >
>> > >
>> > >
>> >
>> >
>>
>
So if I understand the whole picture correctly the situation has actually
nothing to do with directly working OSC in favor of python-*client provided
CLIs but actually moving everything to OSSDK so it can be supported and
used by OSC to be used as default client for everything? As that seems to
be a consensus that it's not enough to get the OSC to do the right thing if
the client lib under the hood is still python-*client and specially if
microversions.

My question at this point is, do we (as a community) have enough bodies
dedicated to OSSDK _and_ OSC to make this sustainable? I'm being sincere
here as I have not been part of the development of either of those
projects. But if my assumption above is correct, I think we should talk
about these things with their real names rather than trying to mask this
being just OSC vs python-*client CLI thing.

- jokke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200813/26d7394f/attachment.html>