<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 13, 2020 at 8:27 AM Sean Mooney <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 2020-08-13 at 10:30 -0400, Artom Lifshitz wrote:<br>
> On Mon, Aug 10, 2020 at 4:40 AM Luigi Toscano <<a href="mailto:ltoscano@redhat.com" target="_blank">ltoscano@redhat.com</a>> wrote:<br>
> > <br>
> > On Monday, 10 August 2020 10:26:24 CEST Radosław Piliszek wrote:<br>
> > > On Mon, Aug 10, 2020 at 10:19 AM Belmiro Moreira <<br>
> > > <br>
> > > <a href="mailto:moreira.belmiro.email.lists@gmail.com" target="_blank">moreira.belmiro.email.lists@gmail.com</a>> wrote:<br>
> > > > Hi,<br>
> > > > during the last PTG the TC discussed the problem of supporting different<br>
> > > > clients (OpenStack Client - OSC vs python-*clients) [1].<br>
> > > > Currently, we don't have feature parity between the OSC and the<br>
> > > > python-*clients.<br>
> > > <br>
> > > Is it true of any client? I guess some are just OSC plugins 100%.<br>
> > > Do we know which clients have this disparity?<br>
> > > Personally, I encountered this with Glance the most and Cinder to some<br>
> > > extent (but I believe over the course of action Cinder got all features I<br>
> > > wanted from it in the OSC).<br>
> > <br>
> > As far as I know there is still a huge problem with microversion handling<br>
> > which impacts some cinder features. It has been discussed in the past and<br>
> > still present.<br>
> <br>
> Yeah, my understanding is that osc will never "properly" support<br>
> microversions.<br>
it does already properly support micorversion the issue is not everyone agrees<br>
on what properly means. the behavior of the project clients was considered broken<br>
by many. it has been poirpose that we explcity allow a way to opt in to the auto negociation<br>
via a new "auto" sentaial value and i have also suggested that we should tag each comman with the minium<br>
microversion that parmater or command requires and decault to that minium based on teh arges you passed.<br>
<br>
both of those imporvement dont break the philosipy of providing stable cli behavior across cloud and would<br>
imporve the ux. defaulting to the minium microversion needed for the arguments passed would solve most of the ux<br>
issues and adding an auto sentical would resolve the rest while still keeping the correct microversion behvior it<br>
already has.<br>
<br>
the glance and cinder gaps are not really related to microverions by the way.<br>
its just that no one has done the work and cinder an glance have not require contiuptors to update<br></blockquote><div><br></div><div>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 <a href="https://review.opendev.org/590807">https://review.opendev.org/590807</a>.</div><div><br></div><div>Alan<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
osc as part of adding new features. nova has not required that either but there were some who worked on nova<br>
that cared enough about osc to mention it in code review or submit patches themsevles. the glance team does<br>
not really have the resouces to do that and the osc team does not have the resouce to maintain clis for all teams.<br>
<br>
so over tiem as service poject added new feature the gaps have increase since there were not people tyring to keep it in<br>
sync.<br>
<br>
>  Openstacksdk is the future in that sense, and my<br>
> understanding is that the osc team is "porting" osc to use the sdk.<br>
> Given these two thing, when we (Nova) talked about this with the osc<br>
> folks, we decided that rather than catch up osc to python-novaclient,<br>
> we'd rather focus our efforts on the sdk.<br>
well that is not entirly a good caraterisation. we want to catch up osc too<br>
but the suggest was to support eveything in osc then it would be easier to add osc support<br>
since it just has to call the sdk functions. we did not say we dont want to close the gaps in osc.<br>
<br>
>  I've been slowly doing that<br>
> [1], starting with the earlier Nova microversions. The eventual long<br>
> term goal is for the Nova team to *only* support the sdk, and drop<br>
> python-novaclient entirely, but that's a long time away.<br>
> <br>
> [1] <a href="https://review.opendev.org/#/q/status:open+project:openstack/openstacksdk+branch:master+topic:story/2007929" rel="noreferrer" target="_blank">https://review.opendev.org/#/q/status:open+project:openstack/openstacksdk+branch:master+topic:story/2007929</a><br>
> <br>
> > <br>
> > <br>
> > --<br>
> > Luigi<br>
> > <br>
> > <br>
> > <br>
> <br>
> <br>
<br>
<br>
</blockquote></div></div>