15:01:20 <slaweq> #startmeeting neutron_qos
15:01:21 <openstack> Meeting started Tue Dec 19 15:01:20 2017 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:25 <openstack> The meeting name has been set to 'neutron_qos'
15:01:34 <slaweq> hello
15:01:54 <slaweq> welcome on last QoS meeting this year :)
15:02:23 <slaweq> mlavalle will be few minutes late so I think we can wait for him
15:02:31 * mlavalle joins the meeting
15:04:08 <slaweq> hi mlavalle
15:04:20 <mlavalle> o/
15:04:24 <slaweq> it looks that we are only two on meeting :/
15:04:45 <mlavalle> let's do a quick one
15:04:59 <slaweq> ok
15:05:08 <slaweq> so first topic is
15:05:12 <slaweq> #topic RFEs
15:05:32 <slaweq> we have one new rfe bug reported:
15:05:40 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1727578
15:05:40 <openstack> Launchpad bug 1727578 in neutron "[RFE]Support apply qos policy in VPN service" [Wishlist,Confirmed]
15:05:45 <slaweq> it's even not triagged yet
15:06:13 <slaweq> and I didn't have time to read it yet
15:06:34 <reedip-holo> Hi
15:06:35 <mlavalle> yamamoto already chimed in
15:06:48 <slaweq> reedip-holo: hi
15:06:49 <mlavalle> it would be great if you can take a look at it
15:07:04 <mlavalle> hey reedip-holo
15:07:09 <slaweq> mlavalle: I will read it carefully tomorow
15:07:19 <mlavalle> thanks :-)
15:07:24 <slaweq> #action slaweq will look at https://bugs.launchpad.net/neutron/+bug/1727578
15:07:25 <openstack> Launchpad bug 1727578 in neutron "[RFE]Support apply qos policy in VPN service" [Wishlist,Confirmed]
15:07:41 <slaweq> next one
15:07:44 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1649517
15:07:44 <openstack> Launchpad bug 1649517 in neutron "qos policy attached to network, qos_policy_id is reflecting on neutron net-show , but not on the port with neutron port-show" [Wishlist,Triaged] - Assigned to Reedip (reedip-banerjee)
15:07:53 <slaweq> mlavalle: it's still waiting for drivers team :)
15:07:54 <reedip-holo> It's still stuck
15:08:14 <slaweq> will be drivers meeting this week?
15:08:18 <mlavalle> it was discussed during last meeting
15:08:38 <slaweq> ah, so I missed logs from it
15:09:34 <mlavalle> the team didn't see a strong reason to implement it
15:09:43 <reedip-holo> ??
15:10:03 <mlavalle> I will update it later today
15:10:10 <slaweq> mlavalle: ok, thx
15:10:15 <mlavalle> and yo can respond there
15:10:26 <slaweq> ok
15:10:41 <mlavalle> but the point was
15:10:59 <mlavalle> that you can always look at the port
15:11:05 <mlavalle> and the show it's network
15:11:09 <mlavalle> then^^^
15:11:23 <mlavalle> and see if it is the same policy
15:11:26 <mlavalle> right?
15:11:33 <slaweq> yes, You can
15:11:46 <reedip-holo> But that's not the exact thing achieved in this RFE, I guess
15:11:47 <slaweq> but it was more for the case when port inherits policy from network
15:11:56 <slaweq> and don't have own policy
15:12:21 <slaweq> then it is not clear that port have got any policy attached
15:12:31 <mlavalle> in that situation.....
15:12:37 <slaweq> unless user will not do network-show for each port which he have
15:13:10 <mlavalle> will the policy-id shown in the port will be the same as in the network?
15:13:40 <slaweq> this patch which reedip-holo did adds additional field to port
15:13:48 <mlavalle> I know
15:13:54 <mlavalle> but currently
15:13:58 <mlavalle> before the patch
15:14:21 <slaweq> before this patch there will be no policy-id if it is inherited from network
15:14:21 <mlavalle> what happens if the port inherited it's network policy?
15:14:25 <slaweq> this field is empty
15:14:35 <reedip-holo> Yep as slaweq said
15:14:37 <slaweq> for port
15:14:46 <mlavalle> so we need to clarify that in the rfe
15:14:55 <mlavalle> we misunderstood
15:15:09 <slaweq> reedip-holo: will You write it there?
15:15:13 <mlavalle> so I will post a response from the last meeting
15:15:15 <reedip-holo> Ok I will
15:15:22 <slaweq> thx
15:15:24 <mlavalle> and then reedip-holo can reply
15:15:31 <reedip-holo> Ok ok
15:15:33 <slaweq> mlavalle: yep, thx
15:15:37 <mlavalle> cool
15:15:53 <reedip-holo> Ok :)
15:16:29 <mlavalle> and it's at the top of the list
15:16:38 <mlavalle> so we will discuss again this Friday
15:16:45 <reedip-holo> Ok gr8
15:16:53 <slaweq> good, thx :)
15:17:10 <slaweq> so moving to next one
15:17:22 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1596611
15:17:22 <openstack> Launchpad bug 1596611 in neutron "[RFE] Create L3 IPs with qos (rate limit)" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889)
15:17:27 <slaweq> this is FIP QoS
15:17:32 <mlavalle> yes
15:17:34 <slaweq> it is almost merged :)
15:17:47 <slaweq> remaining patches waiting for review #link https://review.openstack.org/#/q/topic:bp/floating-ip-rate-limit+(status:open+OR+status:merged)
15:17:56 <mlavalle> I have a couple of questions
15:18:05 <slaweq> mlavalle: shoot
15:18:15 <mlavalle> 1) you tested the agent side and it works, right?
15:18:34 <slaweq> mlavalle: yes, I tested it on my devstack and it looked that it works
15:18:41 <mlavalle> ok
15:19:19 <mlavalle> 2) in the docs patch, he states that if a policy with no limit rules is attached to a FIP, it will do nothing
15:19:21 <slaweq> at least on tc side everything looked good on my side
15:19:54 <slaweq> yes, it is done in same way like it was some time ago for ports/network
15:20:18 <mlavalle> but can't we check that in the server and return BadRequest
15:20:21 <mlavalle> ?
15:20:28 <slaweq> but later we added validation mechanism when policy is attached for port or network
15:20:51 <slaweq> I think we should but I think it can be next step maybe
15:21:15 <mlavalle> slaweq: I agree. I just don't want to leave that in the docs
15:21:35 <mlavalle> or at least clarify that it will be fixed
15:21:41 <slaweq> IMHO it should be like that for now as it is true
15:21:41 <mlavalle> makes sense?
15:21:52 <slaweq> I agree that it can be clarify that it will be changed
15:21:54 <slaweq> yes :)
15:21:59 <mlavalle> ok, cool
15:22:05 <mlavalle> we are good
15:22:24 <slaweq> and also I pointed in this docs patch that some update of qos internal document should be also updated
15:22:35 <mlavalle> did he agree to that?
15:22:40 <slaweq> it is not done still so IMO we should wait for that
15:22:47 <mlavalle> ok
15:23:03 <slaweq> AFAIR he told something about completly new document for FIP QoS
15:23:28 <slaweq> I don't know if it is necessary but maybe his right :)
15:25:16 <slaweq> ok, next one?
15:25:22 <mlavalle> done
15:25:36 <mlavalle> said couple of questions
15:25:57 <slaweq> thx mlavalle
15:26:17 <slaweq> so moving on
15:26:20 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1560963
15:26:20 <openstack> Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,In progress]
15:26:33 <slaweq> this one has no volunteer currently
15:26:48 <mlavalle> is there a patchset already?
15:26:51 <slaweq> and nothing changed since last time about it
15:26:52 <reedip_> I think this wAS taken up by ralonsoh
15:26:59 <reedip_> wasnt it?
15:27:18 <reedip_> if there is some info, I can tke it up
15:27:40 <slaweq> reedip_: it was
15:28:05 <slaweq> but later also hichihara was working on it
15:28:15 <slaweq> but his patch is abandoned for now
15:29:05 <slaweq> and ralonsoh patch for LB was reverted probably because there was something wrong with it
15:29:11 <slaweq> but I'm not sure about that
15:29:23 <reedip_> ok....
15:29:46 <slaweq> if You would have anyone who wants to start working on it, that would be great :)
15:30:10 <reedip_> I can get working on it
15:30:18 <slaweq> reedip_: that would be great
15:30:29 <mlavalle> thanks reedip_
15:30:40 <slaweq> if You will need anything, just ask me on irc
15:30:57 <reedip_> yeah sure :)
15:31:09 <slaweq> thx reedip_
15:31:20 <slaweq> so last rfe which I have for today
15:31:25 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1692951
15:31:25 <openstack> Launchpad bug 1692951 in neutron "[RFE] DSCP mark on the outer header" [Wishlist,In progress] - Assigned to Ali Sanhaji (ali-sanhaji)
15:31:45 <slaweq> I was trying to catch author of this patch on IRC but I couldn't
15:32:07 <slaweq> but I was talking with tmorin and he told me that author should continue his work on it
15:32:37 <slaweq> It was almost ready as I remember
15:33:14 <slaweq> mlavalle: what You think if I would continue work on this patch if author will be still not available for week or two?
15:33:27 <slaweq> because I would like to finish it if it would be possible
15:33:38 <mlavalle> go for it
15:33:54 <slaweq> mlavalle: ok, thx
15:34:13 <slaweq> so I will keep an eye on it
15:34:38 <slaweq> so, next topic is
15:34:43 <slaweq> #topic Bugs
15:35:05 <slaweq> there is couple of QoS related bugs reported
15:35:13 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1662109
15:35:13 <openstack> Launchpad bug 1662109 in neutron "tempest scenario test_qos fails intermittently" [High,In progress] - Assigned to Slawek Kaplonski (slaweq)
15:35:37 <slaweq> recently I was trying to find on logstash if it is still an issue
15:35:56 <slaweq> but it looks that test results from this job are not indexed on logstash
15:36:11 <slaweq> I couldn't find any results from it :/
15:36:56 <slaweq> mlavalle: maybe You can help on checking this logs on logstash? and if job is configured properly?
15:37:26 <mlavalle> slaweq: ok, I will take a look
15:37:32 <slaweq> mlavalle: thx
15:37:41 <slaweq> it's neutron-tempest-plugin-dvr-multinode-scenario job
15:38:04 <slaweq> I can send You query which I was trying on logstash if You want
15:38:15 <slaweq> but that can be after meeting I think
15:39:07 <slaweq> next one
15:39:10 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1733649
15:39:10 <openstack> Launchpad bug 1733649 in neutron "fullstack neutron.tests.fullstack.test_qos.TestDscpMarkingQoSOvs.test_dscp_marking_packets(openflow-native) failure" [High,Confirmed] - Assigned to Slawek Kaplonski (slaweq)
15:39:19 <slaweq> this is also related to failing tests (fullstack)
15:39:46 <slaweq> so I added some additional logs of tcpdump output but this issue didn't happen since few days
15:40:02 <slaweq> so I'm just checking every morning if I will find something
15:40:09 <slaweq> not too much to add here
15:40:52 <slaweq> next one
15:40:55 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1736674
15:40:55 <openstack> Launchpad bug 1736674 in neutron "sg rules are sometimes not applied" [High,In progress] - Assigned to Slawek Kaplonski (slaweq)
15:41:04 <slaweq> that is also assigned to me
15:41:15 <slaweq> and it has patch ready to review: https://review.openstack.org/#/c/527965/
15:41:28 <slaweq> I would be grateful if You could look on it
15:42:09 <reedip_> in my To DO list now
15:42:26 <slaweq> it's related to qos because DSCP marking packets in linuxbridge agent breaks security groups rules in iptables
15:42:28 <slaweq> reedip_: thx
15:42:49 <slaweq> next one is also about failing fullstack test
15:42:51 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1737892
15:42:51 <openstack> Launchpad bug 1737892 in neutron "Fullstack test test_qos.TestBwLimitQoSOvs.test_bw_limit_qos_port_removed failing many times" [High,Confirmed]
15:43:06 <slaweq> I found that it happen few times so I reported it as bug
15:43:14 <slaweq> but I haven't got time to debug it yet
15:44:30 <slaweq> any questions or we can go to next one?
15:45:17 <reedip_> we can move on
15:45:30 <slaweq> mlavalle: are You still with us? :)
15:45:45 <slaweq> so next
15:45:50 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1676877
15:45:50 <openstack> Launchpad bug 1676877 in neutron "Increase "TestQosPlugin.test_update_policy_rule" coverage" [Medium,In progress] - Assigned to Reedip (reedip-banerjee)
15:45:52 <mlavalle> slaweq: yes
15:46:04 <slaweq> reedip_: mlavalle reviewed Your patch today
15:46:11 <slaweq> reedip_: please check his comments
15:46:17 <slaweq> mlavalle: great :)
15:46:19 <reedip_> I would tomorrow...
15:46:35 <mlavalle> I'm ok with the code
15:46:40 <reedip_> I am tired today ( its 2115 here )
15:46:48 <slaweq> reedip_: sure :)
15:46:54 <mlavalle> I just think the commit message doesn't reflect all the code does
15:47:17 <reedip_> okie dokie
15:47:45 <slaweq> ok, next one is #link https://bugs.launchpad.net/neutron/+bug/1736792
15:47:46 <openstack> Launchpad bug 1736792 in neutron "DSCP marking QOS policy applied to port not properly updating OVS flow table" [Medium,New]
15:48:03 <slaweq> it was reported for Newton release
15:48:17 <slaweq> so I think that we should first check if it's still an issue for master
15:49:11 <mlavalle> good idea :-)
15:49:16 <slaweq> I will add it to my list of todos but if someone would have time to check it, would be great
15:49:41 <slaweq> #action slaweq check if https://bugs.launchpad.net/neutron/+bug/1736792 is still an issue on master
15:49:41 <openstack> Launchpad bug 1736792 in neutron "DSCP marking QOS policy applied to port not properly updating OVS flow table" [Medium,New]
15:49:57 <slaweq> next #link https://bugs.launchpad.net/neutron/+bug/1724729
15:49:57 <openstack> 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:50:08 <slaweq> patch is in review: #link https://review.openstack.org/#/c/513398/
15:50:20 <slaweq> please review if You will have some time
15:51:07 <reedip_> TO do List
15:51:16 <slaweq> reedip_: thx
15:51:51 <slaweq> ok, and the last one for today #link https://bugs.launchpad.net/neutron/+bug/1732852
15:51:51 <openstack> Launchpad bug 1732852 in neutron "neutron don't support Router gateway rate limit " [Low,In progress] - Assigned to Slawek Kaplonski (slaweq)
15:51:57 <slaweq> this is not new one
15:52:03 <slaweq> patch for docs is already merged
15:52:10 <slaweq> but it's kind of workaround only
15:52:26 <slaweq> in future we should probably think how to fix it in better way :)
15:53:36 <slaweq> any questions to those bugs?
15:53:40 <slaweq> reedip_: mlavalle ?
15:54:25 <mlavalle> none from me
15:55:32 <slaweq> ok
15:55:36 <slaweq> so last topic for today
15:55:38 <slaweq> #topic Open Discussion
15:55:45 <slaweq> I don't have anything
15:55:53 <slaweq> do You have something to add?
15:55:54 <mlavalle> me neither
15:55:59 <reedip_> Sorry I disconnected
15:56:08 <reedip_> Nothing from my side
15:56:26 <reedip_> Seems my PC is more sleepy than me
15:56:35 <slaweq> ok, so Merry Christmass and Happy New Year
15:56:44 <slaweq> next meeting will be in 2018 :)
15:56:55 <slaweq> reedip_: :D
15:57:09 <reedip_> Happy New Year and Merry Christmas... We would be having Q3 soon so enjoy the holidays
15:57:12 <reedip_> :D
15:57:24 <slaweq> thx
15:57:32 <slaweq> #endmeeting