14:00:58 <slaweq> #startmeeting neutron_qos
14:00:59 <openstack> Meeting started Wed Nov 30 14:00:58 2016 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:02 <openstack> The meeting name has been set to 'neutron_qos'
14:01:02 <slaweq> hello
14:01:07 <ralonsoh> Hi
14:01:54 <slaweq> I hope there will be more people in few minutes :)
14:02:01 <ralonsoh> no problem
14:02:22 <ralonsoh> BTW, the etherpad is https://etherpad.openstack.org/p/neutron_qos_meeting_chair?
14:03:00 <slaweq> no, I was preparing it today's agenda on https://etherpad.openstack.org/p/qos-meeting
14:03:13 <ralonsoh> ok
14:03:25 <ralonsoh> one sec
14:04:06 <slaweq> ok
14:04:23 <ralonsoh> I updated the etherpad for today
14:04:27 <slaweq> thx
14:04:38 <ralonsoh> but, if there is no qorum, it's useless
14:04:48 <slaweq> yep :/
14:05:23 <slaweq> btw ralonsoh: can You review https://review.openstack.org/#/c/401458/ if You will have a while?
14:05:48 <ralonsoh> I'll review this today
14:05:53 <slaweq> thx
14:06:17 <slaweq> davidsha, njohnston, reedip: are You there?
14:06:32 <davidsha> hi, just joined
14:06:36 <slaweq> hello
14:07:11 <davidsha> This is the LB-dscp is it?
14:07:18 <ralonsoh> yes
14:07:18 <slaweq> davidsha: yes
14:07:34 <slaweq> please review if You will have time - You are dscp master :)
14:08:09 <davidsha> ack,  I have very little knowledge of LB but I'll try to review it.
14:08:18 <slaweq> ok, so maybe we will start and do it quick, what You think?
14:08:29 <ralonsoh> perfect
14:08:38 <slaweq> #topic RFEs-approved
14:08:48 <slaweq> there is no too many rfe-approved for QoS
14:08:59 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1578989
14:08:59 <openstack> Launchpad bug 1578989 in neutron "[RFE] Strict minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:09:09 <slaweq> ralonsoh: how it's going?
14:09:25 <ralonsoh> The first part, which is the BW manager, goes fine
14:09:31 <ralonsoh> one sec
14:09:39 <ralonsoh> BW manager, OVS: https://review.openstack.org/#/c/404343/
14:09:45 <ralonsoh> BW manager, LB: https://review.openstack.org/#/c/402121/
14:09:49 <ralonsoh> BW manager, SR-IOV: https://review.openstack.org/#/c/401254/
14:09:55 <ralonsoh> BW manager, config options: https://review.openstack.org/#/c/404647/
14:09:58 <ralonsoh> to review...
14:10:16 <ralonsoh> The frist three I want to someone to see the architecture
14:10:34 <ralonsoh> That's all
14:10:54 <davidsha> kk, I added myself to the reviews
14:11:00 <ralonsoh> Thanks!
14:11:06 <slaweq> #action slawek review ralonsoh patches with BW manager
14:11:07 <hichihara> ralonsoh: I'll review it
14:11:18 <slaweq> ok, I will also have a look on it
14:11:22 <ralonsoh> hichihara: thanks!
14:11:56 <ralonsoh> next RFE, I think
14:12:00 <slaweq> other rfe-approved bugs are same as last time (extended validation and instance ingress) and nothing changes there on my side
14:12:22 <slaweq> maybe ajo will have something to update on his patch https://review.openstack.org/#/c/351858/
14:12:38 <slaweq> but as I checked it today, there was no too many changes there
14:12:41 <slaweq> so
14:12:44 <slaweq> #topic RFEs
14:13:08 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1644369
14:13:08 <openstack> Launchpad bug 1644369 in neutron "Support for DSCP marking in Linuxbridge L2 agent" [Wishlist,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:13:29 <slaweq> I made it last week, patch is ready for review (IMHO) so please take a look on it
14:13:36 <ralonsoh> Sur
14:13:39 <ralonsoh> Sure
14:13:46 <slaweq> I made it with iptables rule to mark packets with dscp
14:13:52 <slaweq> any questions to this one?
14:14:46 <slaweq> ok, so maybe next one
14:14:53 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1634798
14:14:53 <openstack> Launchpad bug 1634798 in neutron "[RFE] Qos DSCP to vlan priority mapping" [Wishlist,Confirmed]
14:15:08 <slaweq> this one is new IMO and is not assigned yet
14:15:28 <ralonsoh> I need to take a look to this one
14:15:37 <ralonsoh> I'll try to reply in launchpad
14:15:43 <slaweq> ok, thx ralonsoh
14:16:07 <davidsha> slaweq: There was a Vlan pcp rfe a while back but it went obsolete, would that be needed before this?
14:16:37 <slaweq> davidsha: I don't know
14:16:41 <slaweq> it's something to check
14:17:14 <slaweq> davidsha: do You have link to it?
14:17:19 <ralonsoh> davidsha is right
14:17:25 <ralonsoh> #link https://review.openstack.org/#/c/392023/
14:17:25 <davidsha> vikram said he was going to wait for dscp to merge before he started work on it I think, give me one sec and I'll find it
14:18:17 <davidsha> Oh, it's the bug linked in that spec: https://bugs.launchpad.net/neutron/+bug/1505631
14:18:17 <openstack> Launchpad bug 1505631 in neutron "[RFE] QoS VLAN 802.1p Support" [Wishlist,Confirmed] - Assigned to Kannan Raman (kannanrc20)
14:19:20 <davidsha> thanks ralonsoh!
14:19:20 <slaweq> but this one is postponed currently
14:19:39 <ralonsoh> The spec is now approved
14:20:00 <ralonsoh> No
14:20:11 <ralonsoh> not yet
14:21:04 <slaweq> yes, but in https://bugs.launchpad.net/neutron/+bug/1634798 ajo asked what author means there so maybe we should wait for answear there?
14:21:04 <openstack> Launchpad bug 1634798 in neutron "[RFE] Qos DSCP to vlan priority mapping" [Wishlist,Confirmed]
14:21:32 <ralonsoh> Yes, we should wait for the previous one
14:21:43 <slaweq> ok, so going forward
14:21:50 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1505627
14:21:50 <openstack> Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Incomplete] - Assigned to Reedip (reedip-banerjee)
14:21:54 <slaweq> this one is quite old
14:22:19 <slaweq> so I don't think we should talk about it again now
14:22:22 <slaweq> what You think?
14:22:44 <ralonsoh> vikram or reedip should ask this question
14:23:03 <slaweq> but it seems that they are not here
14:23:18 <ralonsoh> next time then
14:23:34 <slaweq> ok
14:23:54 <slaweq> #topic Bugs
14:24:11 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1640757
14:24:11 <openstack> Launchpad bug 1640757 in neutron "Parameter validation for string type parameters" [Undecided,Incomplete] - Assigned to Slawek Kaplonski (slaweq)
14:24:17 <slaweq> I was checking it
14:24:30 <slaweq> and I described everything in comments
14:24:42 <slaweq> IMHO there is no bug there but maybe You have something to add
14:24:52 <ralonsoh> I agree with your comments
14:25:07 <ralonsoh> This could be also a problem in other objects
14:25:11 <ralonsoh> But it's not
14:25:13 <slaweq> so should we close this bug?
14:25:18 <ralonsoh> I think so
14:25:45 <slaweq> ok, I will close it
14:25:57 <slaweq> #action slaweq close https://bugs.launchpad.net/neutron/+bug/1640757
14:25:57 <openstack> Launchpad bug 1640757 in neutron "Parameter validation for string type parameters" [Undecided,Incomplete] - Assigned to Slawek Kaplonski (slaweq)
14:26:07 <slaweq> https://bugs.launchpad.net/neutron/+bug/1640762
14:26:07 <openstack> Launchpad bug 1640762 in neutron "when I update a Qos policy, value of shared can not be changed to false from true" [Undecided,Incomplete] - Assigned to Slawek Kaplonski (slaweq)
14:26:22 <slaweq> I also checked it and IMHO there is also no issue there
14:26:37 <slaweq> there is flag to set shared/not shared qos policy
14:26:51 <ralonsoh> With OSC?
14:26:55 <ralonsoh> I need to check that
14:26:58 <slaweq> yep, I checked in OSC
14:27:13 <ralonsoh> I did this patch
14:27:15 <slaweq> in neutron client I added such flag even
14:27:28 <slaweq> in OSC it is also but name is littlebit different
14:27:44 <slaweq> I pasted there my test with OSC
14:27:52 <ralonsoh> I see
14:28:08 <ralonsoh> I'll ask in the bug:
14:28:14 <slaweq> ok
14:28:15 <ralonsoh> which version of OSC
14:28:22 <ralonsoh> and how to reproduce it
14:28:38 <slaweq> https://bugs.launchpad.net/neutron/+bug/1616547
14:28:39 <openstack> Launchpad bug 1616547 in neutron "qos: rule api definition shouldn't include tenant_id" [Low,Incomplete]
14:29:01 <slaweq> about this one I have note that ralonsoh wanted to check it last time
14:29:09 <slaweq> do You have any info about it?
14:29:49 <ralonsoh> rule doesn't include tenant_id
14:29:58 <davidsha> was this not changed from tenant_id to project_id?
14:30:36 <ralonsoh> Ok
14:30:43 <ralonsoh> Yes, it has
14:30:51 <ralonsoh> And it was changed to project_id
14:31:21 <slaweq> I'm not sure but I think that there was something like that reported some time ago and it was not provided "accidentally"
14:31:49 <ralonsoh> "rule" is a neutronobject
14:31:55 <ralonsoh> so it has project_id
14:32:04 <ralonsoh> Should be in the api definition
14:32:18 <slaweq> so ralonsoh can You update it in this bug report?
14:32:23 <ralonsoh> ok
14:32:26 <slaweq> thx
14:32:45 <slaweq> next https://bugs.launchpad.net/neutron/+bug/1616411
14:32:45 <openstack> Launchpad bug 1616411 in neutron "the result is not expected from the command "neutron qos-policy-show policy -F id"" [Undecided,New] - Assigned to QunyingRan (ran-qunying)
14:33:15 <slaweq> I don't know if author of this one is here
14:34:36 <davidsha> doesn't seem like it, not on #openstack-neutron either
14:34:37 <slaweq> do You have anything to add for this one?
14:34:39 <hichihara> It looks like a bug of neutronclient
14:34:49 <slaweq> yep
14:35:28 <slaweq> there is also one more for neutronclient: #link https://bugs.launchpad.net/neutron/+bug/1643849
14:35:28 <openstack> Launchpad bug 1643849 in python-neutronclient "The result of 'qos-minimum-bandwidth-rule-list' is wrong" [High,In progress] - Assigned to QunyingRan (ran-qunying)
14:36:25 <slaweq> anything to add here?
14:36:46 <ralonsoh> It's under review: https://review.openstack.org/#/c/401824/
14:36:53 <ralonsoh> I'll take a look at this
14:36:58 <slaweq> ok
14:37:14 * ajo appears ':)
14:37:23 <slaweq> shouldn't we check also OSC if it is valid for it also?
14:37:28 <slaweq> hello ajo :)
14:37:54 <ralonsoh> OSC patch is still under review.... for 3 months
14:38:03 <ralonsoh> OSC is still not ready for this
14:38:19 <slaweq> ok, so OSC is not impacted by this bug :)
14:38:23 <ralonsoh> no
14:38:38 <slaweq> next one #link https://bugs.launchpad.net/neutron/+bug/1644097
14:38:38 <openstack> Launchpad bug 1644097 in neutron "qos tempest tests should not try to use unsupported rule types" [Low,Triaged]
14:38:58 <slaweq> I can look on this one later
14:39:38 <ajo> oh, that makes sense, right. Otherwise plugins not suporting DSCP will go red.
14:40:06 <slaweq> but in tempest there are only tests for LB and OVS agents, right?
14:40:10 <slaweq> or SR-IOV also?
14:40:51 <slaweq> and what is tested in tempest in fact? are there tests which really check if packets are marked with DSCP?
14:41:07 <ajo> hmmm
14:41:13 <ajo> tempest should be plugin agnosti
14:41:16 <ajo> agnostic
14:41:22 <ajo> it's just a a tool to validate your cloud
14:41:27 <ajo> (afaik)
14:41:35 <hichihara> Right
14:41:53 <slaweq> yes, but if tests are only checking if rule is applied on api level then it will not be red for any plugin/agent
14:42:15 <slaweq> at least as long as we don't do "improved validation" :)
14:42:23 <ajo> hmm
14:42:41 <ajo> for bandwidth I think there were some tests that checked bandwidth
14:42:42 <slaweq> but I agree that it should be fixed
14:42:43 <ajo> not sure for dscp
14:43:01 <ajo> or may be it's because midonet's plugin does not allow creation of rules it doesn't support
14:43:05 <slaweq> I made such test for dscp in fullstack tests but I don't know about tempest
14:43:20 <slaweq> I will check it
14:43:21 <ajo> in a multi-backend enviroment
14:43:30 <ajo> all plugins would have to allow creation of any policy
14:43:50 <ajo> and then... (when we have the rule validation) fail if you try to use a rule your backend doesn't support
14:44:13 <slaweq> ok
14:44:24 <ajo> I talked about that with yamamoto the other day
14:44:48 <ajo> may be it just has to wait until we finish rule validation, and that's it
14:45:13 <slaweq> You mean this change in tempest?
14:45:47 <ajo> yes,
14:46:00 <ajo> or we can do as yamamoto requested
14:46:07 <ajo> and not try rules not reported as available
14:46:26 <slaweq> I will check how it looks in tests code
14:46:40 <slaweq> and if I will find something I will describe in comments in this bug
14:46:41 <ajo> ack, thanks slaweq  :=
14:46:42 <ajo> :)
14:47:02 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1507656
14:47:02 <openstack> Launchpad bug 1507656 in neutron "RPC callbacks push/pull mechanism should be remotable" [Wishlist,Opinion] - Assigned to Ihar Hrachyshka (ihar-hrachyshka)
14:47:11 <slaweq> I found also this one tagged as qos
14:47:21 <slaweq> but I don't know if it is valid for now?
14:48:08 <ajo> we don't need to look at opinion bugs
14:48:17 <slaweq> ok
14:48:23 <ajo> opinion means = we won't fix it, it's an oppinion of the reporter
14:48:30 <slaweq> sorry, I didn't know
14:48:34 <slaweq> still learning
14:48:41 <ajo> or something like that
14:48:42 <ajo> :D
14:48:43 <ajo> so we can skip it :D
14:48:44 <ajo> np, it's confusing :D
14:48:45 <ajo> thanks for helping with this btw :D
14:49:08 <slaweq> #link https://bugs.launchpad.net/neutron/+bug/1639186
14:49:08 <openstack> Launchpad bug 1639186 in neutron "qos max bandwidth rules not working for neutron trunk ports" [Low,Confirmed] - Assigned to Luis Tomas Bolivar (ltomasbo)
14:49:35 <slaweq> ajo: do You know how it's going?
14:49:42 <ltomasbo> hi
14:49:50 <slaweq> hello ltomasbo
14:50:21 <ajo> ltomasbo can explain it better :D
14:50:21 <ltomasbo> I just tried a simple patch to connect trunk port with br-int with veth devices
14:50:35 <ltomasbo> so that QoS bw can be used
14:51:03 <ltomasbo> and make it configurable (so that you can choose if those ovs bridges are to be link thorugh patch or veth links
14:51:16 <ltomasbo> however, that is not a good solution to merge upstream
14:51:34 <ltomasbo> and seems the prefered solution is to be able to apply the bw throttling at ovs patch ports
14:52:03 <ltomasbo> but it will be nice to hear more opinions
14:52:09 <ltomasbo> and other possible solutions
14:52:25 <qwebirc15108> good
14:52:26 <ralonsoh> but it's not possible to set egress qos rules in OVS
14:52:38 <ltomasbo> although I agree with armax and think it should be done at OVS first
14:52:40 <ralonsoh> (ingress for OVS)
14:53:03 <ajo> yes,
14:53:07 <ajo> if we want something that works for dpdk
14:53:11 <ajo> and does not introduce more overhead
14:53:11 <hichihara> +1 > OVS first
14:53:20 <ajo> we may need this kind of feature in OVS
14:53:26 <ajo> (via metering, etc..)
14:53:43 <ajo> I'm not sure how interested they'd be in that, metering packets adds overhead
14:53:47 <ajo> but may be it's not that much
14:54:37 <ltomasbo> ralonsoh: ingress for OVS works right now, right?
14:54:44 <slaweq> will qos works fine on ovs with patch-ports? I'm asking because AFAIR for example for internal ports it was not working properly
14:54:58 <ralonsoh> only for interfaces, not for ports
14:55:23 <ltomasbo> the problem here is that instead of having a tap device connected to the br-int, for trunk ports you have a patch port that connects to another ovs-brdige, which connects to the VM
14:55:40 <davidsha> ralonsoh: is it not the other way around?
14:56:11 <ralonsoh> davidsha: what do you mean? I don't understand
14:56:21 <ralonsoh> we can talk about this by mail
14:56:22 <hichihara> Is it possible if use veth?
14:56:30 <ralonsoh> it is
14:56:38 <ltomasbo> yep, I tried that and it works
14:56:39 <ralonsoh> but hurting a lot the performance
14:56:42 <ajo> it works if the port has a linux kernel interface
14:56:43 <ajo> a tap port, a veth, etc
14:56:44 <ajo> but not a patch port
14:56:50 <ajo> correct
14:56:58 <hichihara> ralonsoh: yes
14:56:58 <ajo> that's why what ltomasbo tested works, but it's not desired
14:57:02 <davidsha> ralonsoh: qos tables are added on the port not interface. I think I may have misunderstood though.
14:57:36 * ajo wants https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.3.0.pdf. Section 5.7 :)
14:57:38 <ralonsoh> davidsha: yes, on the port. But qos max bw in Neutron is setting the interface policing
14:58:12 <davidsha> ralonsoh: yes, sorry!
14:58:21 <ajo> right,
14:58:43 <hichihara> Excuse me, I have one item before meeting end.
14:59:02 <slaweq> ok, give it hichihara :)
14:59:08 <hichihara> I work on https://review.openstack.org/#/c/318531/
14:59:15 <hichihara> But the implementaion about tunneling(VXLAN) is a bit complicated.
14:59:21 <hichihara> I think that it'll be independent of VLAN.
14:59:25 <hichihara> So I'll divide the patch into two patches(VLAN and Tunneling).
14:59:36 <hichihara> Maybe I'll update VLAN patch early next week.
14:59:41 <ralonsoh> ?
14:59:42 <hichihara> That's all :)
14:59:56 <ralonsoh> ok....
15:00:14 <hichihara> ralonsoh: Please check
15:00:19 <slaweq> ok, I think we are out of time now
15:00:28 <slaweq> #endmeeting