15:00:46 <slaweq> #startmeeting neutron_qos
15:00:47 <openstack> Meeting started Tue Mar 27 15:00:46 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:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:50 <openstack> The meeting name has been set to 'neutron_qos'
15:00:56 <slaweq> hi on another meeting :)
15:01:01 <rubasov> hi again
15:01:16 <slaweq> hi rubasov
15:01:34 <slaweq> mlavalle: will You attend?
15:01:40 <mlavalle> o/
15:01:48 <mlavalle> of course
15:01:52 <slaweq> great
15:02:19 <slaweq> I don't think there will be anyone else here so we can start IMO
15:02:25 <slaweq> #topic RFEs
15:02:37 <slaweq> first rfe
15:02:40 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1596611
15:02:41 <openstack> Launchpad bug 1596611 in neutron "[RFE] Create L3 floating IPs with qos (rate limit)" [Wishlist,Fix committed] - Assigned to LIU Yulong (dragon889)
15:02:56 <slaweq> I would like to announce that it's finally done
15:03:05 <slaweq> scenario tests are merged finally
15:03:05 <mlavalle> \o/
15:03:22 <slaweq> there is some issue with DVR but it will be treated as bug
15:03:46 <slaweq> so rfe and BP can be closed finally (if it isn't yet)
15:04:19 <slaweq> actually it is marked as "fix commited" so that's fine also
15:04:27 <slaweq> so, next rfe is #link https://bugs.launchpad.net/neutron/+bug/1727578
15:04:28 <openstack> Launchpad bug 1727578 in neutron "[RFE]Support apply qos policy in VPN service" [Wishlist,Triaged]
15:05:10 <slaweq> there wasn't to much changes on this one recently but today zhaobo6 wrote there that he will continue work on this specs
15:05:25 <slaweq> specs is at https://review.openstack.org/#/c/531074/
15:05:49 <slaweq> so I don't think that there is anything to add on this one today
15:06:21 <slaweq> next one on my list is #link https://bugs.launchpad.net/neutron/+bug/1560963
15:06:22 <openstack> Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,In progress]
15:06:49 <slaweq> and TBH I didn't have any time to work on PoC for such backend implementation for minimum bandwidth
15:07:21 <slaweq> if there is someone else who would like to work on it - feel free to take it :)
15:07:53 <slaweq> I will try to email ralonsoh and ask for some details how he planned to do it in the past
15:07:57 <mlavalle> when we say eggress...
15:08:28 <mlavalle> who's point of view is that?
15:08:39 <slaweq> it's VM's point of view
15:08:57 <slaweq> so this is direction which is harder to implement
15:09:19 <slaweq> but it's the one which makes more sense from user's perspective
15:10:09 <rubasov> I'm a bit lost
15:10:16 <slaweq> rubasov: why?
15:10:21 <rubasov> isn't this completed for at least SR-IOV?
15:10:28 <slaweq> for SR-IOV yes
15:10:35 <mlavalle> https://docs.openstack.org/neutron/latest/admin/config-qos.html
15:10:42 <rubasov> is the RFE for all drivers then?
15:10:44 <slaweq> but it isn't done for linuxbridge and for ovs
15:10:52 <njohnston> o/
15:10:55 <rubasov> okay, got it, thanks
15:11:01 <mlavalle> ahhh ok, that is what got rubasov and me confused
15:11:10 <slaweq> it was quite easy to do it for sr-iov
15:11:20 <slaweq> but it is much harder for other backends
15:11:43 <slaweq> as traffic which is egress from VM is in fact ingress from bridge perspective
15:11:51 <mlavalle> yeap
15:12:00 <slaweq> and tc don't do shaping on ingress :/
15:12:04 <mlavalle> we cannot shape it
15:12:16 <slaweq> so we will probably need to play with ifb devices to achieve that
15:12:29 <slaweq> but I have no any experience with this
15:13:35 <mlavalle> I guess time to experiment and learn
15:13:50 <slaweq> mlavalle: yes, excactly :)
15:14:03 <slaweq> so, moving on to the next one?
15:14:10 <mlavalle> +
15:14:35 <slaweq> next one is #link https://bugs.launchpad.net/neutron/+bug/1578989
15:14:36 <openstack> Launchpad bug 1578989 in neutron "[RFE] Strict minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Slawek Kaplonski (slaweq)
15:14:51 <slaweq> and it is related to previous one :)
15:15:12 <slaweq> rubasov: You are working on it now, right?
15:15:20 <rubasov> I just uploaded a new patch set for the spec
15:15:39 <slaweq> yes, I saw it and will try to do review today or tomorrow morning
15:15:51 <rubasov> includes an idea how to use binding:profile
15:16:03 <mlavalle> rubasov: did my comment about using binding:vnic_type and binding:profile make sense?
15:16:10 <mlavalle> great
15:16:11 <rubasov> tomorrow I hope to look into how qos rule validation work
15:16:22 <rubasov> mlavalle: absolutely
15:16:30 <slaweq> rubasov: ping me if You will have any questions about this validation
15:16:45 <slaweq> I was doing it so I hope I will be able to help :)
15:16:51 <mlavalle> I think the same will aplly to the spec on the nova side
15:17:15 <mlavalle> we can simplify several things by comminicating with binding:profile
15:17:15 <rubasov> because I'm not yet satisfied with having two rules (one for data plane enforcement, one for placement enforcement) either
15:17:24 <rubasov> slaweq: will do, thanks
15:18:14 <mlavalle> today I will try to provide feedback on the Nova side
15:18:17 <rubasov> mlavalle: yep, it simplifies for neutron, but it complicates for nova
15:18:37 <mlavalle> and tomorrow I will try to come back to the Neutron one
15:18:41 <rubasov> mlavalle: because that information first has to go down to nova-compute (today it does not)
15:19:04 <rubasov> mlavalle: but I'm talking about that to gibi
15:19:13 <mlavalle> ok
15:21:07 <slaweq> I want also to mention that lajoskatona_ did 2 patches related to this rfe for neutron-lib: https://review.openstack.org/#/c/554532/ and https://review.openstack.org/#/c/552938/
15:21:18 <slaweq> please add it to Your list of reviews :)
15:21:43 <rubasov> I hope to catch up with Lajos's patches soon
15:21:50 <slaweq> rubasov: thx
15:22:03 <lajoskatona_> Slaweq: I just on the way to refresh one of those
15:22:39 <slaweq> lajoskatona_: thx for info
15:22:56 <mlavalle> Nice!
15:23:55 <slaweq> moving on to the next one
15:24:05 <slaweq> there is one postponed rfe: #link https://bugs.launchpad.net/neutron/+bug/1505627
15:24:06 <openstack> Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Triaged] - Assigned to Reedip (reedip-banerjee)
15:24:47 <slaweq> I just wanted to mention that reedip told me recently that he should soon work on it again
15:25:51 <slaweq> if there are no questions about rfe we can go to next topic I think
15:25:53 <njohnston> since this is just enabling ECN autonegotiation as opposed to actually managing anything within ECN I think this should be not too difficult
15:26:17 <slaweq> njohnston: right, I think that this one should be easy to implement
15:28:02 <slaweq> ok, going on to next topic
15:28:04 <slaweq> #topic Bugs
15:28:23 <slaweq> there is one "fresh" bug #link https://bugs.launchpad.net/neutron/+bug/1758316
15:28:24 <openstack> Launchpad bug 1758316 in neutron "Floating IP QoS don't work in DVR router" [High,Confirmed] - Assigned to LIU Yulong (dragon889)
15:28:40 <slaweq> it is related to FIP QoS and DVR
15:29:01 <slaweq> I found that it's not working fine in our dvr scenario job
15:29:28 <slaweq> so for now I added patch to skip this test if dvr is enabled: https://review.openstack.org/#/c/555747/
15:29:49 <slaweq> and I hope that LIU Yulong will find out why it's not working properly
15:30:48 <mlavalle> is he aware?
15:31:00 <slaweq> yes, he even wrote some comment there
15:31:04 <mlavalle> ok
15:31:20 <mlavalle> he is good following up
15:31:26 <slaweq> I will try to ask him about progress this week
15:31:53 <slaweq> any questions on this one?
15:32:28 <mlavalle> not from me
15:32:47 <njohnston> nope
15:32:56 <slaweq> ok, I have also 2 old bugs on my list:
15:33:00 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1639186
15:33:01 <openstack> Launchpad bug 1639186 in neutron "qos max bandwidth rules not working for neutron trunk ports" [Low,Confirmed]
15:33:07 <slaweq> and #link https://bugs.launchpad.net/neutron/+bug/1732852
15:33:09 <openstack> Launchpad bug 1732852 in neutron "neutron don't support Router gateway rate limit " [Low,In progress]
15:33:30 <slaweq> with both of them still nothing changed since long time
15:34:14 <slaweq> speaking about #link https://bugs.launchpad.net/neutron/+bug/1732852 - I don't know if we can do anything with it
15:34:15 <openstack> Launchpad bug 1732852 in neutron "neutron don't support Router gateway rate limit " [Low,In progress]
15:34:30 <slaweq> that can only work if veth will be used
15:34:56 <slaweq> but I don't know if we can do anything else except mention that constraint in docs
15:35:10 <slaweq> like was done some time ago: https://review.openstack.org/#/c/523153/
15:36:05 <slaweq> I know that Ihar wanted to enforce using veth if rate limit is used but I'm not sure if that is good approach
15:36:15 <slaweq> mlavalle: what do You think about that?
15:37:18 <mlavalle> don't know. let me look into it
15:37:29 <mlavalle> I'll get back to you
15:37:53 <slaweq> mlavalle: sure, maybe You can just wrote a comment in this bug report if You will read it
15:38:03 <mlavalle> I will do that
15:38:15 <slaweq> thx a lot mlavalle
15:38:28 <slaweq> and that was all on my bugs list for today
15:38:36 <slaweq> any questions?
15:38:43 <slaweq> something to add?
15:38:47 <mlavalle> nope
15:38:54 <mlavalle> pretty good update
15:39:00 <slaweq> thx
15:39:07 <mlavalle> thanks for keeping track of all this
15:39:23 <njohnston> +1 really awesome job slaweq
15:39:32 <slaweq> so if anyone has anything to other to talk about I think we can finish earlier today :)
15:39:34 <slaweq> njohnston: thx :)
15:39:50 * slaweq will have few minutes before next meeting
15:40:00 <slaweq> thx for attending guys
15:40:09 <slaweq> and btw. happy easter to all of You
15:40:32 <mlavalle> Same to you!
15:40:38 <slaweq> thx
15:40:42 <slaweq> #endmeeting