15:00:55 #startmeeting neutron_qos 15:00:56 Meeting started Tue Jan 16 15:00:55 2018 UTC and is due to finish in 60 minutes. The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:00 The meeting name has been set to 'neutron_qos' 15:01:09 hi 15:01:12 Hi 15:01:16 Hi all 15:01:47 please give me one minute and I will be back 15:02:00 o/ 15:04:17 ok, I'm back 15:04:25 let's start 15:04:33 #topic RFEs 15:05:00 we have still couple approved RFEs 15:05:05 #link https://bugs.launchpad.net/neutron/+bug/1560963 15:05:06 Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,In progress] 15:05:13 there is nothing new with this one 15:05:20 not assigned to anyone 15:06:04 so if anyone would be interested in doing that, would be great :) 15:06:27 next one #link https://bugs.launchpad.net/neutron/+bug/1578989 15:06:28 Launchpad bug 1578989 in neutron "[RFE] Strict minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Miguel Lavalle (minsel) 15:06:48 it's waiting for next cycle as we decided some time ago with mlavalle 15:07:03 correct 15:07:07 but ralonsoh did some patches related to it 15:07:18 and he pushed placement api client to neutron-lib 15:07:30 one patch is already merged: #link https://review.openstack.org/#/c/511936/ 15:07:41 and second is in review: #link https://review.openstack.org/#/c/512396/ 15:08:03 so please review it if You will have some time 15:08:28 next is almost done: #link https://bugs.launchpad.net/neutron/+bug/1596611 15:08:29 Launchpad bug 1596611 in neutron "[RFE] Create L3 IPs with qos (rate limit)" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889) 15:08:51 only docs and tempest tests are still in review 15:09:07 tempest tests are marked as WIP so I didn't review it yet 15:09:39 I will take a look at the tempest tests 15:09:45 docs are almost ready IMO 15:09:49 ok, thx mlavalle 15:10:21 next is #link https://bugs.launchpad.net/neutron/+bug/1692951 15:10:22 Launchpad bug 1692951 in neutron "[RFE] DSCP mark on the outer header" [Wishlist,In progress] - Assigned to Ali Sanhaji (ali-sanhaji) 15:10:22 that is my impresion also 15:10:46 I just rebased for this one 15:10:56 after raryk comment 15:10:59 garyk 15:11:06 great that it's not only for me :) 15:11:20 alisanhaji: yes, thx a lot 15:11:48 no need to :) 15:12:02 mlavalle: please review https://review.openstack.org/#/c/501267/ if You will have some time 15:12:16 I will check it today or tomorrow also 15:12:41 I hope it can be merged finally soon :) 15:12:50 yes me too 15:13:41 alisanhaji: I saw that garyk gave +1 already :) 15:13:49 * mlavalle will take a loom also 15:13:49 yes just saw it too 15:14:16 ok, and the last (but not least) one is #link https://bugs.launchpad.net/neutron/+bug/1727578 15:14:17 Launchpad bug 1727578 in neutron "[RFE]Support apply qos policy in VPN service" [Wishlist,Triaged] 15:14:34 there is specs proposed for it already: #link https://review.openstack.org/#/c/531074/ 15:14:50 mlavalle: again, please add it to Your review list :) 15:15:23 this RFE was approved last drivers meeting 15:15:35 so the spec is timely 15:16:08 :) 15:16:32 there was some doubts from yamamoto about how that would be implemented 15:16:53 so if you can give some guidance, slaweq, it would be very usful 15:17:05 I mean from your QoS perspective 15:17:10 from QoS point of view it looks like it can be some beginning of classful bw limits 15:17:35 as I understand it, there will be rules based on src/dest IP addresses added in router's namespace 15:17:37 cool, please provide that guidance in the spec 15:17:53 yes, I was already reviewing it once or twice 15:17:58 :-) 15:18:00 I will check it also this week 15:18:39 ok, so that was all RFEs which I had for today 15:19:00 #topic Bugs 15:19:48 fortunately there is not too many bugs reported for QoS :) 15:19:57 first one is #link https://bugs.launchpad.net/neutron/+bug/1662109 15:19:58 Launchpad bug 1662109 in neutron "tempest scenario test_qos fails intermittently" [High,In progress] - Assigned to Slawek Kaplonski (slaweq) 15:20:39 I still can't check if this is still an issue in gate - I didn't found it in my tests and logstash query for it is still not working IMO 15:20:52 mlavalle: we talked about that some time ago :) 15:20:56 do You remember? 15:21:08 yes 15:21:24 can we maybe check it this week once again? 15:21:28 yes 15:21:37 ok, thx 15:21:46 I will ping You later 15:22:28 next one: #link https://bugs.launchpad.net/neutron/+bug/1737892 15:22:29 Launchpad bug 1737892 in neutron "Fullstack test test_qos.TestBwLimitQoSOvs.test_bw_limit_qos_port_removed failing many times" [High,In progress] - Assigned to Slawek Kaplonski (slaweq) 15:22:51 patch for this one is almost merged 15:23:06 in fact it is not an issue in QoS code but in ovs agent 15:23:46 I will probably add also similar fullstack test for DSCP marking rule as such rule can be also not removed when port is removed from bridge 15:24:22 ah, and patch related to this bug is on #link https://review.openstack.org/#/c/533318/ 15:25:13 any questions/suggestions so far? 15:27:21 mlavalle: alisanhaji: still here? :) 15:27:27 yes 15:27:29 yes 15:27:32 y 15:27:32 should I continue? 15:27:39 please go ahead 15:27:42 ok 15:27:52 I am following 15:28:01 so if there is no questions then next bug 15:28:02 #link https://bugs.launchpad.net/neutron/+bug/1736792 15:28:03 Launchpad bug 1736792 in neutron "DSCP marking QOS policy applied to port not properly updating OVS flow table" [Medium,New] 15:28:13 for me it is duplicate of https://bugs.launchpad.net/neutron/+bug/1739411 15:28:15 Launchpad bug 1739411 in neutron "QoS DSCP mark disappear stable/ocata" [Low,Confirmed] - Assigned to Pavlukhin Max (mpavlukhin) 15:28:22 and I would mark if as duplicate 15:28:30 mlavalle: do You agree? 15:28:41 mhhh, hang on.... 15:28:45 sure 15:29:23 yes, I agree 15:29:59 ok, so I will close it after meeting 15:30:12 so about https://bugs.launchpad.net/neutron/+bug/1739411 15:30:18 Launchpad bug 1739411 in neutron "QoS DSCP mark disappear stable/ocata" [Low,Confirmed] - Assigned to Pavlukhin Max (mpavlukhin) 15:30:28 there is already proposed patch: #link https://review.openstack.org/#/c/529315/ 15:30:39 but there is no response from author for it 15:30:55 I will try to catch him and ask if he can continue this work 15:30:59 or I will handle it 15:31:22 #action slaweq check progress on #link https://review.openstack.org/#/c/529315/ 15:31:57 next is #link https://bugs.launchpad.net/neutron/+bug/1724729 15:31:58 Launchpad bug 1724729 in neutron "ovs-lib not support qos type egress-policer for ovs-dpdk" [Low,In progress] - Assigned to Slawek Kaplonski (slaweq) 15:32:13 and patch is waiting for review: #link https://review.openstack.org/#/c/513398/ 15:32:21 mlavalle: thx for Your review last week 15:32:51 I changed units according to Your comments as it's in fact different for dpdk ports :) 15:33:07 yeah, I was surprised by that 15:33:13 me too 15:33:24 I don't know why they decided to do it that way 15:33:33 me neighter 15:33:46 I will take a look again today 15:33:52 and I was double checking that it's differently for dpdk ports and for "normal" ports 15:34:01 thx 15:34:11 on the other hand, their doc is pretty good 15:34:33 yes, everything is described there quite clearly 15:34:34 or blog entry or whatever it is 15:35:26 next one is our "old friend": #link https://bugs.launchpad.net/neutron/+bug/1639186 15:35:28 Launchpad bug 1639186 in neutron "qos max bandwidth rules not working for neutron trunk ports" [Low,Confirmed] 15:35:42 there is no volunteer to work on it still 15:35:47 so nothing new 15:36:38 and the last one on my list for today is #link https://bugs.launchpad.net/neutron/+bug/1732852 15:36:39 Launchpad bug 1732852 in neutron "neutron don't support Router gateway rate limit " [Low,In progress] - Assigned to Slawek Kaplonski (slaweq) 15:36:45 there is also nothing new here 15:37:25 I don't have time for it still :/ 15:38:05 and as it is documented how it should be configured to make it working I think it's not high priority now 15:38:35 ok 15:39:31 so that are all bugs which I have for You today 15:39:36 any questions? 15:39:43 none from me 15:39:53 no questions 15:40:23 so last topic in agenda is 15:40:24 #topic Open Discussion 15:40:35 I don't have anything here 15:40:40 I would like to discuss a new spec that I proposed with alisanhaji for congestion reaction in overlay networks using neutron qos policy. #link https://review.openstack.org/#/c/534213/2 15:41:44 A previous version was proposed by reedip to activate ECN in openstack network and routers. https://review.openstack.org/#/c/445762/ 15:42:24 so it is continuation of reedip's work? 15:42:43 We can see that. 15:42:47 So, this one proposes new qos policy that handles the congestion in all phases, starting by ensuring ECN activation because it’s essential to congestion detection, going through the congestion calculation. Finally we react to the congestion if it exceeded the defined threshold using bandwidth limit qos rule. 15:44:12 so You want to change bandwidth limit rules dynamically when it is necessary? 15:45:36 Yes, we use the bandwidth limit rule dynamically en ensure that the source of congestion reduced its traffic, then we release it if the congestion goes below 15:46:14 so source VM will don't need to know about this ECN and don't need to support it 15:46:26 as it will be "supported" by Neutron's QoS rules, right? 15:47:28 fouadben: I will read this spec this week and will left comments there 15:47:32 This solution enfore the ECN activation what ever the VM OS configuration. Everything starts out of the VM. 15:47:48 Thanks slaweq 15:47:50 ok 15:47:53 slaweq: yes that's it, the VM doesn't need to know about ECN 15:48:00 that is good :) 15:48:16 I think that You will also need to fill RFE bug about that 15:48:19 mlavalle: right? 15:48:31 yes, I think so 15:48:35 Already pub https://bugs.launchpad.net/neutron/+bug/1708460 15:48:36 Launchpad bug 1708460 in neutron " [RFE] Reaction to network congestion for qos" [Wishlist,New] - Assigned to Fouad Benamrane (ftreqah) 15:49:18 ok, I will look at it soon 15:49:19 ah, I didn't saw it linked as related-bug in commit message in specs so I thought it's not done yet 15:49:26 thx mlavalle 15:49:53 and thx fouadben and alisanhaji for this proposal :) 15:50:07 y welcome 15:50:22 anything else? 15:50:29 none from me 15:50:35 if not we can finish earlier today :) 15:50:39 no 15:51:12 mlavalle: do You have anything else to add? 15:51:18 nope 15:51:37 ok, so thanks everyone 15:51:38 thanks for chairing this meeting, slaweq :-) 15:51:49 #endmeeting