<div dir="ltr">Thank you Slawek</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Slawek Kaplonski <<a href="mailto:skaplons@redhat.com">skaplons@redhat.com</a>> ezt írta (időpont: 2020. szept. 17., Cs, 10:22):<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
On Thu, Sep 17, 2020 at 08:49:30AM +0200, Lajos Katona wrote:<br>
> Hi,<br>
> The neutron-lib patch is necessary for the use case when the new QoS<br>
> min_kbps value for the port is 0.<br>
> So would be good to have that on Victoria as well.<br>
<br>
Ok, so I personally think that it would be still good to merge it now, backport<br>
neutron-lib fix and make bugfix release of neutron-lib for Victoria.<br>
<br>
> <br>
> Regards<br>
> Lajos<br>
> <br>
> Slawek Kaplonski <<a href="mailto:skaplons@redhat.com" target="_blank">skaplons@redhat.com</a>> ezt írta (időpont: 2020. szept. 16.,<br>
> Sze, 22:21):<br>
> <br>
> > Hi,<br>
> ><br>
> > For me personally it seems ok to merge approve this FFE as this change<br>
> > isn't<br>
> > very big and is limited only to the QoS service plugin. So IMHO risk of<br>
> > merging<br>
> > that isn't very big.<br>
> > There is also scenario test proposed for that feature in [1] so we can<br>
> > ensure<br>
> > that it is working fine.<br>
> ><br>
> > On Wed, Sep 16, 2020 at 02:39:27PM +0200, Lajos Katona wrote:<br>
> > > Hi<br>
> > > The neutron-lib patch (<a href="https://review.opendev.org/750349" rel="noreferrer" target="_blank">https://review.opendev.org/750349</a> ) is a bug fix<br>
> > > (see [1]) which as do not touch db or API can be backported later in the<br>
> > > worst case.<br>
> ><br>
> > Is ther neutron-lib patch necessary to make all of that working so that<br>
> > without<br>
> > backporting this fix and releasing new version feature in neutron will not<br>
> > work<br>
> > at all?<br>
> ><br>
> > > The fix itself doesn't affect other Neutron features, so no harm.<br>
> > ><br>
> > > Thanks for your help.<br>
> > > Regards<br>
> > > Lajos Katona (lajoskatona)<br>
> > ><br>
> > > [1] <a href="https://launchpad.net/bugs/1894825" rel="noreferrer" target="_blank">https://launchpad.net/bugs/1894825</a><br>
> > ><br>
> > > Sean McGinnis <<a href="mailto:sean.mcginnis@gmx.com" target="_blank">sean.mcginnis@gmx.com</a>> ezt írta (időpont: 2020. szept.<br>
> > 15.,<br>
> > > K, 18:05):<br>
> > ><br>
> > > > > I would like to ask for FFE for the RFE "allow replacing the QoS<br>
> > > > > policy of bound port", [1].<br>
> > > > > This feature adds the extra step to port update operation to change<br>
> > > > > the allocation in Placement to the min_kbps values of the new QoS<br>
> > > > > policy, if the port has a QoS policy with minimum_bandwidth rule and<br>
> > > > > is bound and used by a server.<br>
> > > > ><br>
> > > > > In neutron there's one open patch:<br>
> > > > > <a href="https://review.opendev.org/747774" rel="noreferrer" target="_blank">https://review.opendev.org/747774</a><br>
> > > > ><br>
> > > > > There's an open bug report for the neutron-lib side:<br>
> > > > > <a href="https://bugs.launchpad.net/neutron/+bug/1894825" rel="noreferrer" target="_blank">https://bugs.launchpad.net/neutron/+bug/1894825</a> (placement story:<br>
> > > > > <a href="https://storyboard.openstack.org/#!/story/2008111" rel="noreferrer" target="_blank">https://storyboard.openstack.org/#!/story/2008111</a> )  and a fix for<br>
> > that:<br>
> > > > > <a href="https://review.opendev.org/750349" rel="noreferrer" target="_blank">https://review.opendev.org/750349</a><br>
> > > > ><br>
> > > > > [1] <a href="https://bugs.launchpad.net/neutron/+bug/1882804" rel="noreferrer" target="_blank">https://bugs.launchpad.net/neutron/+bug/1882804</a><br>
> > > > ><br>
> > > > Since this requires an update to neutron-lib, adding [requirements] to<br>
> > > > the subject. Non-client library freeze was two weeks ago now, so it's a<br>
> > > > bit late.<br>
> > > ><br>
> > > > The fix looks fairly minor, but I don't know that code. Can you comment<br>
> > > > on the potential risks of this change? We should be stabilizing as much<br>
> > > > as possible at this point as we approach the final victoria release<br>
> > date.<br>
> > > ><br>
> > > > Sean<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > ><br>
> ><br>
> > [1] <a href="https://review.opendev.org/#/c/743695" rel="noreferrer" target="_blank">https://review.opendev.org/#/c/743695</a><br>
> ><br>
> > --<br>
> > Slawek Kaplonski<br>
> > Senior software engineer<br>
> > Red Hat<br>
> ><br>
> ><br>
<br>
-- <br>
Slawek Kaplonski<br>
Senior software engineer<br>
Red Hat<br>
<br>
</blockquote></div>