15:01:23 <slaweq> #startmeeting neutron_qos
15:01:24 <openstack> Meeting started Tue Jul 17 15:01:23 2018 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:27 <slaweq> hi again
15:01:28 <openstack> The meeting name has been set to 'neutron_qos'
15:01:37 <slaweq> #topic RFEs
15:01:38 <rubasov> hello again
15:01:51 <njohnston> o/
15:02:20 <mlavalle> o/
15:02:46 <slaweq> let's go quickly through RFEs
15:02:50 <slaweq> first one is #link https://bugs.launchpad.net/neutron/+bug/1560963
15:02:50 <openstack> Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,In progress]
15:03:04 <slaweq> and I didn't made any progress with it
15:03:16 <slaweq> so I don't think that there is anything to talk about it
15:03:35 <slaweq> unless there is someone who wants to work on it maybe :)
15:03:38 <mlavalle> but you had a great vacation, didn't you?
15:03:47 <slaweq> yes mlavalle, I had :)
15:03:52 <slaweq> thx
15:04:19 <slaweq> so next one is:
15:04:21 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1727578
15:04:21 <openstack> Launchpad bug 1727578 in neutron "[RFE]Support apply qos policy in VPN service" [Wishlist,Triaged]
15:04:34 <slaweq> for this one there is WIP patch #link https://review.openstack.org/#/c/558986/
15:04:48 <slaweq> but there wasn't any activity on it in last few weeks also
15:05:37 <slaweq> zhaobo6 is probably not here now
15:05:43 <mlavalle> I don't think we are going to have much activity over the next couple of weeks
15:06:13 <mlavalle> it is the same author as the port forwarding series
15:06:22 <mlavalle> and he is working hard on this
15:06:23 <slaweq> I think it's not urgent for now
15:06:45 <slaweq> thx for update mlavalle
15:06:47 <mlavalle> But I want to mention that it is an important feature for my employer
15:07:02 <mlavalle> which is the same as Zhaobo
15:07:18 <mlavalle> so he will definitile reyurn to it
15:07:27 <slaweq> so we can expect that it will be Your priority in next cycle? :)
15:07:47 <mlavalle> it might. But more likely Zhaobo's
15:08:02 <slaweq> great
15:08:38 <slaweq> next one which I want to mention is: #link https://bugs.launchpad.net/neutron/+bug/1757044
15:08:38 <openstack> Launchpad bug 1757044 in neutron "[RFE] neutron L3 router gateway IP QoS" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889)
15:08:47 <slaweq> it still waits for drivers team now
15:09:14 <slaweq> so mlavalle please add it to Your drivers team agenda maybe, or check author's responses to Your questions there
15:09:18 <slaweq> thx in advance
15:09:19 <mlavalle> we discussed it during the meeting  about 4 weeks ago
15:09:33 <mlavalle> and we had a couple of questions
15:09:51 <mlavalle> which Liu Yulong answerd until last week
15:09:55 <slaweq> bug report was updated recently
15:10:09 <slaweq> he answered for Your questions I think
15:10:17 <mlavalle> I know
15:10:32 <mlavalle> and I had it as tiem #1 for last Friday's meeting
15:10:39 <slaweq> ok, thx. I just wanted to mention that here :)
15:10:41 <mlavalle> we didn't have quorum, though
15:10:58 <mlavalle> it will be the first item we discuss in the next meeting
15:11:50 <slaweq> great, thx mlavalle
15:12:09 <slaweq> so now let's talk about most important RFEs :)
15:12:15 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1578989
15:12:15 <openstack> Launchpad bug 1578989 in neutron "[RFE] Strict minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Lajos Katona (lajos-katona)
15:12:29 <slaweq> rubasov: lajoskatona: do You have something to update?
15:12:52 <rubasov> a bit
15:13:00 <rubasov> I know that two weeks before the feature freeze many has higher priorities
15:13:02 <lajoskatona> Slaweq: Hi, I started to work on the direction extension for minimum bw rule
15:13:11 <rubasov> but if you have free time we always appreciate reviews on this topic: https://review.openstack.org/#/q/status:open+topic:minimum-bandwidth-allocation-placement-api
15:13:43 <lajoskatona> Slaweq: and now started the extension as well for port_resource_request to propagate the qis stuff fro nova via port dict
15:13:47 <rubasov> there's a bunch of stuff coming together there
15:13:53 <mlavalle> rubasov, lajoskatona: thanks for your work an update
15:14:12 <slaweq> I started slowly some reviews of those patches
15:14:13 <rubasov> one major part is to synchronize placement resource provider info from agent to server to placement
15:14:20 <rubasov> slaweq: thank you
15:15:14 <lajoskatona> Slaweq, mlavalle: thanks, hope that soon we can have again some end-to-end thing, to see how to move forward
15:15:14 <mlavalle> I will take a look at those patches as soon as I dig myself out of the port forwarding seires ;-)
15:15:37 <slaweq> I will review them also ASAP
15:15:46 <rubasov> if you like to look at stuff early I think even the patches marked as WIP are quite readable and ready for some input
15:16:22 <slaweq> ok rubasov, thx for info
15:16:51 <mlavalle> ahhh, you meant early in development, not early in the day....
15:16:57 <mlavalle> just joking ;-)
15:17:07 <slaweq> LOL
15:17:26 <slaweq> those patches are good to review only in the morning, before first coffee :P
15:17:31 <rubasov> mlavalle: you're in the right time zone to follow everything we do early in the day :-)
15:17:48 <mlavalle> you are right
15:18:05 <rubasov> mlavalle: ;-)
15:19:22 <slaweq> ok, let's move on to next topic then
15:19:25 <slaweq> #topic Bugs
15:19:44 <slaweq> we have couple new bugs for QoS reported recently
15:19:52 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1781915
15:19:52 <openstack> Launchpad bug 1781915 in neutron "QoS (DSCP Mark IDs) – No correlation between the implemented functionality and design" [High,Fix released] - Assigned to Nate Johnston (nate-johnston)
15:20:09 <slaweq> this is documentation issue which njohnston already fixed
15:20:12 <slaweq> thx njohnston
15:20:20 <mlavalle> ++
15:20:27 <njohnston> :-)
15:20:41 <slaweq> next one is
15:20:44 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1778666
15:20:45 <openstack> Launchpad bug 1778666 in neutron "QoS - “port” parameter is required in CLI in order to set/unset QoS policy to floating IP" [Low,Confirmed]
15:21:31 <slaweq> I read it today and it looks for me like some bug in Neutron code, we have to check if that's true
15:22:22 <slaweq> if there will be anyone else who will take it in next few days, I will take a look on it
15:25:25 <slaweq> next bug is: #link https://bugs.launchpad.net/neutron/+bug/1778740
15:25:25 <openstack> Launchpad bug 1778740 in neutron "Quality of Service (QoS) in Neutron - associating QoS policy to Floating IP" [Low,Confirmed]
15:25:50 <slaweq> and this is also only documentation issue, so easy to fix :)
15:26:43 <slaweq> next one, also related to docs: #link https://bugs.launchpad.net/neutron/+bug/1779052
15:26:43 <openstack> Launchpad bug 1779052 in neutron "Quality of Service (QoS) in Neutron (documentation) - only different types rules can be combined in QoS policy" [Low,In progress] - Assigned to yanpuqing (ycx)
15:26:49 <slaweq> patch propsed already: #link https://review.openstack.org/581941
15:26:55 <slaweq> please review it :)
15:27:31 <slaweq> actually, I reviewed it today and it has to be updated
15:27:44 <slaweq> so probably You can wait with review :)
15:28:13 <slaweq> next one is:
15:28:16 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1776160
15:28:16 <openstack> Launchpad bug 1776160 in neutron "'burst' does not take effect for neutron egress qos bindlimit by ovs" [Undecided,New]
15:28:23 <slaweq> and this one looks that might be serious
15:29:02 <slaweq> I will try to verify it this week and update bug and do the fix for it maybe
15:30:31 <mlavalle> ok
15:31:49 <slaweq> and the last one is related to FIP QoS: #link https://bugs.launchpad.net/neutron/+bug/1781892
15:31:52 <openstack> Launchpad bug 1781892 in neutron "QoS – Neutron port is not effected after association “Floating IP” with “QoS policy” enabled" [Undecided,New]
15:32:02 <slaweq> this should be verified also by someone
15:32:19 <slaweq> I don't know if I will have time this week for all of those bugs
15:32:24 <mlavalle> slaweq: I'll try to take a look
15:32:29 <slaweq> thx mlavalle
15:33:00 <slaweq> if I will have time and it will be not taken, I will get it but I'm just not sure
15:33:27 <slaweq> it looks like some problem on API level
15:33:35 <mlavalle> me niether, but I'll do my best
15:33:41 <slaweq> mlavalle: thx a lot
15:34:15 <mlavalle> it's a good thing that this guy Arkady is looking at the floating ip stuff
15:34:20 <slaweq> there are steps how to reproduce it and as it looks like issue in API/DB so should be easy to verify :)
15:35:04 <slaweq> I think he is guy from RH and is working on some implementation of QoS in networking-odl now
15:35:16 <slaweq> but I might be wrong :)
15:35:33 <mlavalle> https://www.linkedin.com/in/arkady-shtempler-31044b1b/
15:35:35 <slaweq> so he is testing QoS in neutron now
15:35:41 <mlavalle> I think you are right
15:36:05 <mlavalle> He is in Israel
15:36:17 <slaweq> it's very good that there is someone who is reporting those issues - at least we have something to work on ;)
15:37:01 <njohnston> +100
15:37:19 <slaweq> ok, that's all from me for today
15:37:37 <slaweq> if You don't have anything else to add we can get 20 minutes back :)
15:38:46 <mlavalle> you got a deal
15:39:45 <slaweq> ok, thx for attending and see You in 2 weeks :)
15:39:46 <lajoskatona> Bye
15:39:48 <slaweq> bye
15:39:51 <slaweq> #endmeeting