[neutron] Neutron OVN+QoS Support

Ammad Syed syedammad83 at gmail.com
Tue Nov 23 13:47:20 UTC 2021


Hi Erlon,

You can check below url for testing qos on FIP. I have tested it and it
works fine.

https://github.com/openstack/neutron/blob/master/doc/source/admin/config-qos.rst

Ammad
On Tue, Nov 23, 2021 at 6:06 PM Erlon Cruz <sombrafam at gmail.com> wrote:

> Hi Roman, Rodolfo,
>
> I tested setting the QoS policy to the port (internal) instead of the
> network (external), and it works! I did some more testing on
> the OVS vs OVN deployments and I can confirm the status you are saying.
> What I got was:
>
> OVS:
> FIP:
> Setting on port: FAIL
> Setting on network: OK
>
> Private network:
> Setting on port: OK
> Setting on network: OK
>
> Router:
> Internal port: OK
> External port: OK
>
> OVN:
> FIP:
> Setting on port: FAIL
> Setting on network: FAIL (I was trying this)
>
> Private network:
> Setting on port: OK
> Setting on network: OK
>
> Router:
> Internal port: FAIL
> External port: FAIL
>
> Thanks a lot for your help!!
> Erlon
>
> Em ter., 23 de nov. de 2021 às 08:47, Rodolfo Alonso Hernandez <
> ralonsoh at redhat.com> escreveu:
>
>> Hello Erlon:
>>
>> We really need to review the gaps document, at least for Xena.
>>
>> As Roman said, we have been testing QoS in OVN successfully.
>>
>> The current status of QoS in OVN is (at least for Xena):
>> - Fixed ports (VM ports): support for BW limit rules (egress/ingress) and
>> DSCP (only egress). Neutron supports port network QoS inheritance (same as
>> in your example). This is not for OVN but for any backend.
>> - FIPs: support for BW limit rules (egress/ingress). Still no network QoS
>> inheritance (in progress).
>> - GW IP: no support yet.
>>
>> Ping me in #openstack-neutron channel (ralonsoh) if you have more
>> questions.
>>
>> Regards.
>>
>>
>> On Tue, Nov 23, 2021 at 12:12 PM Roman Safronov <rsafrono at redhat.com>
>> wrote:
>>
>>> Hi Erlon,
>>>
>>> There was a bug with setting QoS on a network but it had been fixed long
>>> ago.
>>> https://bugs.launchpad.net/neutron/+bug/1851362  or
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1934096
>>> At least in our downstream CI we do not observe such issues with
>>> QoS+OVN.
>>>
>>> From the commands I see that you apply the QoS rule on the external
>>> network, right?
>>>
>>> On Tue, Nov 23, 2021 at 12:39 PM Erlon Cruz <sombrafam at gmail.com> wrote:
>>>
>>>> Hi Roman,
>>>>
>>>> Forgot to add that detail, since I run the same routine in a non-ovn
>>>> deployment and it worked. But this is how I did it:
>>>>
>>>> openstack network qos policy list
>>>> openstack network qos policy create bw-limiter
>>>> openstack network qos rule create --type bandwidth-limit --max-kbps 512
>>>> --max-burst-kbits 512 --egress bw-limiter
>>>> openstack network qos rule create --type bandwidth-limit --max-kbps 512
>>>> --max-burst-kbits 512 --ingress bw-limiter
>>>> openstack network set --qos-policy bw-limiter ext_net
>>>>
>>>> I didn't set it in the port though, which is something I should do.
>>>> I'll set it in the port too for testing but I think the above should
>>>> work regardless.
>>>>
>>>> Erlon
>>>>
>>>>
>>>> Em seg., 22 de nov. de 2021 às 18:45, Roman Safronov <
>>>> rsafrono at redhat.com> escreveu:
>>>>
>>>>> Hi Erlon,
>>>>>
>>>>> I have a couple of questions that probably will help to understand the
>>>>> issue better.
>>>>> Have you applied the QoS rules on a port, network or floating ip?
>>>>> Have you applied the QoS rules before starting the VM (before it's
>>>>> port is active) or after?
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> On Mon, Nov 22, 2021 at 10:53 PM Erlon Cruz <sombrafam at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi folks,
>>>>>>
>>>>>> I have a question related to the Neutron supportability of OVN+QoS. I
>>>>>> have checked the config reference for both
>>>>>> Victoria and Xena[1]
>>>>>> <https://docs.openstack.org/neutron/xena/admin/config-qos.html>[2]
>>>>>> <https://docs.openstack.org/neutron/xena/admin/config-qos.html> and
>>>>>> they are shown as supported (bw limit, eggress/ingress), but I tried to set
>>>>>> up an env
>>>>>> with OVN+QoS but the rules are not being effective (VMs still
>>>>>> download at maximum speed). I double-checked
>>>>>> the configuration in the neutron API and it brings the QoS settings
>>>>>> [3]
>>>>>> <https://gist.github.com/sombrafam/f8434c0505ed4dd3f912574e7ccebb82>
>>>>>> [4]
>>>>>> <https://gist.github.com/sombrafam/785beb10f20439c4e50eb633f294ae82>
>>>>>> [5]
>>>>>> <https://gist.github.com/sombrafam/b171a38d8cd16bd4dc77cfee3916dccd>,
>>>>>> and the versions[6]
>>>>>> <https://gist.github.com/sombrafam/5d098daa1df3f116d599c09c96eab173>
>>>>>> [7]
>>>>>> <https://gist.github.com/sombrafam/d51102e3a32be5dc8ca03d7a23b6a998> I'm
>>>>>> using should support it.
>>>>>>
>>>>>> What makes me more confused is that there's a document[8]
>>>>>> <https://docs.openstack.org/neutron/xena/ovn/gaps.html>[9]
>>>>>> <https://docs.openstack.org/neutron/victoria/ovn/gaps.html> with a
>>>>>> gap analysis of the OVN vs OVS QoS functionality
>>>>>> and the document *is* being updated over the releases, but it still
>>>>>> shows that QoS is not supported in OVN.
>>>>>>
>>>>>> So, is there something I'm missing?
>>>>>>
>>>>>> Erlon
>>>>>> _______________
>>>>>> [1] https://docs.openstack.org/neutron/victoria/admin/config-qos.html
>>>>>> [2] https://docs.openstack.org/neutron/xena/admin/config-qos.html
>>>>>> [3] QoS Config:
>>>>>> https://gist.github.com/sombrafam/f8434c0505ed4dd3f912574e7ccebb82
>>>>>> [4] neutron.conf:
>>>>>> https://gist.github.com/sombrafam/785beb10f20439c4e50eb633f294ae82
>>>>>> [5] ml2_conf.ini:
>>>>>> https://gist.github.com/sombrafam/b171a38d8cd16bd4dc77cfee3916dccd
>>>>>> [6] neutron-api-0 versions:
>>>>>> https://gist.github.com/sombrafam/5d098daa1df3f116d599c09c96eab173
>>>>>> [7] nova-compute-0 versions:
>>>>>> https://gist.github.com/sombrafam/d51102e3a32be5dc8ca03d7a23b6a998
>>>>>> [8] Gaps from ML2/OVS-OVN Xena:
>>>>>> https://docs.openstack.org/neutron/xena/ovn/gaps.html
>>>>>> [9] Gaps from ML2/OVS-OVN Victoria:
>>>>>> https://docs.openstack.org/neutron/victoria/ovn/gaps.html
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>> --
Regards,


Syed Ammad Ali
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20211123/5ba287e1/attachment-0001.htm>


More information about the openstack-discuss mailing list