<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Aug 13, 2020 at 4:46 PM Alan Bishop <<a href="mailto:abishop@redhat.com">abishop@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"><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" target="_blank">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" target="_blank">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></blockquote></div></div></blockquote><div><br></div><div>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.<br><br></div><div>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.</div><div><br></div><div>- jokke<br></div></div></div>