14:02:02 #startmeeting neutron_qos 14:02:03 Meeting started Wed Apr 6 14:02:02 2016 UTC and is due to finish in 60 minutes. The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:02:07 The meeting name has been set to 'neutron_qos' 14:02:28 let's start by open bugs. 14:02:34 #topic bugs 14:02:41 njohnston was pinging me about one of them 14:02:55 o/ 14:03:02 hi 14:03:04 #link https://launchpad.net/bugs/1564820 14:03:05 Launchpad bug 1564820 in neutron "DSCP rules won't get updated on ports" [Medium,In progress] - Assigned to Nate Johnston (nate-johnston) 14:03:20 I need to review the code but anybody feel free to do it, it's probably ready 14:03:32 it has one +2 already, so I am hopeful 14:04:17 #link https://bugs.launchpad.net/neutron/+bug/1563720 14:04:18 Launchpad bug 1563720 in neutron "Bandwidth limiting for linuxbridge agent works for ingress traffic instead of egress" [High,In progress] - Assigned to Slawek Kaplonski (slaweq) 14:04:32 slaweq is working on this other one, I think it's probably ready 14:04:40 even though I have a -1 set on it 14:04:42 ajo: is it backportable? 14:04:51 ihrachys, yes, made as backportable 14:05:00 no db changes, no new config, and it clears any old wrong policy 14:05:08 on the ports via tc.. 14:05:35 I found something interesting, that I saw once in old Centos7 kernels 14:05:37 ajo: + cleanup 14:05:52 policing does not work well on ubuntu trusty 14:06:11 I'm investigating if it's a kernel issue, a sysctl issue, a hypervisor level issue, or ... a TCP client issue 14:06:22 so we can document it properly, 14:06:46 you set for example an egress limit of 1Mbps, 100kbs burst, 14:06:58 and, egress speed never reaches 1Mbps, 14:07:03 it stays low at 100kbps 14:07:07 because TCP does not adapt properly 14:07:55 my faded memories tell me it's a tcp client issue, because when I saw that long ago with the old centos kernel, I found that connecting via ext net from an OSX, windows, etc... it worked as expected 14:08:04 even on the same hypervisor 14:08:24 but, I'm verifying all the combinations to make sure the feature is robust 14:09:19 #link https://bugs.launchpad.net/neutron/+bug/1507761 14:09:22 Launchpad bug 1507761 in neutron "qos wrong units in max-burst-kbps option (per-second is wrong)" [Low,In progress] - Assigned to Slawek Kaplonski (slaweq) 14:09:23 slaweq doesn't seem to be around 14:10:03 that may need more reviews: 14:10:05 ajo: ok, I just assume that ^ is backwards compat for API 14:10:06 #link https://review.openstack.org/#/c/291633/ 14:10:27 yes, I have to review again to make sure it is 14:10:33 nice on avoiding alembic too 14:10:39 well, api tests may prove it 14:10:41 yes 14:10:52 +1 14:11:04 I see we modify api tests 14:11:15 we should leave them as is, and add more scenarios using new name 14:11:22 that would prove we don't break anyone 14:11:31 ihrachys: +1, yes, I was expecting what you said 14:11:51 hdaniel, ping 14:12:07 sorry, I can't jump to RFE's yet :) I was about to do it :) 14:13:12 we also have 14:13:14 #link https://bugs.launchpad.net/neutron/+bug/1515533 14:13:15 Launchpad bug 1515533 in neutron "QoS policy is not enforced when using a previously used port" [Low,Incomplete] 14:13:30 with this patch: 14:13:35 #link https://review.openstack.org/#/c/255669/ 14:13:58 14:13:58 Bhalachandra Banavalikar 14:14:02 anybody knows what his nick is? 14:14:22 I'm not convinced about the fix, I just belive it's masking another error 14:14:29 or there's a corner case I'm not seeing 14:15:37 I left him another message on the review 14:16:02 any other bug to be noted? 14:16:42 There are also a couple of DSCP follow-up changes that don't have corresponding bugs, but they are both waiting to respond to negative feedback. 14:16:51 https://review.openstack.org/#/c/294463/ 14:17:00 and https://review.openstack.org/#/c/300501/ 14:17:15 * ajo reads 14:17:47 ahh, I see that Margaret is waiting for a response from me on first one 14:18:10 and davidsha is working on second one 14:18:28 #action ajo help margaret with reviews on https://review.openstack.org/#/c/294463/ 14:18:47 I know ihrachys is working with davidsha on the 2nd one but I'll have a read too 14:19:00 I also see this one abandoned: 14:19:03 #link https://launchpad.net/bugs/1486607 14:19:04 Launchpad bug 1486607 in neutron "tenants seem like they were able to detach admin enforced QoS policies from ports or networks" [Low,Confirmed] 14:19:14 #link https://review.openstack.org/#/c/217092/ 14:19:30 if somebody has time to rebase and take ownership of ^ 14:19:43 it's been abandoned for 4 weeks now 14:19:48 why is it low? 14:19:51 yeah, I'll take a look at it 14:20:05 ihrachys, commit message is wrong 14:20:10 ihrachys, tenants are not able to do it 14:20:11 ah ok 14:20:19 it's API response that is wrong? 14:20:20 ihrachys, they just seem to be able to do it, server says OK, but does nothing 14:20:23 ok 14:20:25 exactly 14:20:29 then it's Normal I think, not Low 14:20:31 I don't have the ability to un-abandon it, I think I need a core for that 14:20:34 since API misbehaves 14:20:50 njohnston: restored 14:20:53 njohnston++ 14:20:56 thanks a lot 14:21:09 sure thing! 14:21:19 ihrachys, can you raise the bug prio? 14:21:37 sorry, I did it myself 14:21:54 stupid thing to ask for, it was just a click ':D 14:23:03 ok, RFE's 14:23:35 afaik, haim is teaming up with davidsha to look at 14:23:40 #topic RFEs 14:23:46 #link https://bugs.launchpad.net/neutron/+bug/1527671 14:23:47 Launchpad bug 1527671 in neutron "[RFE] traffic classification in Neutron QoS" [Wishlist,Incomplete] 14:24:06 ajo: I assume the first step is getting neutron-classifier repo in shape? 14:24:11 ajo: or do we shortcut? 14:24:15 the traffic classification lib is probably immature yet, so we may need to push it to make sure we can do it 14:24:20 I would not shortcut 14:24:23 let's do things right 14:24:29 kk 14:24:35 +1 14:24:40 if we have to help with that effort, let's do it first 14:24:46 and then we use it for qos 14:25:02 ihrachys, does that sound reasonable?, or too ambitious for a goal? :) 14:25:09 (or even too optimistic) 14:25:09 I won't have time for that specifically, but I can help somewhat if it's using objects ;) 14:25:22 I am fine for the right thing. it may take time 14:25:24 though 14:25:32 ihrachys, we will have to use objects, since we will need to push the rules with traffic classification stuff to agents 14:25:59 I am open to review object stuff 14:26:27 good :) 14:26:29 #link https://bugs.launchpad.net/neutron/+bug/1560961 14:26:31 Launchpad bug 1560961 in neutron "[RFE] Allow instance-ingress bandwidth limiting" [Wishlist,Confirmed] - Assigned to Slawek Kaplonski (slaweq) 14:26:34 slaweq took that one :) 14:26:48 and hdaniel may team with him too, OVS and LB low level code for that is ready 14:27:27 #link https://bugs.launchpad.net/neutron/+bug/1560963 14:27:27 Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,Confirmed] 14:27:33 I filled that one, 14:27:43 and it's been scoped to only egress traffic to start, 14:28:10 since it's the one that can happen with no integration with external stuff to the hypervisor (gateways, other nodes, etc) 14:28:31 ajo: hi, /me got confused by that daytime savings thing 14:28:37 hdaniel, np :) 14:28:48 for min_bandwidth in OVS 14:28:55 I had an action pending from last meeting 14:29:09 and it was checking that set_queue openflow action was useful to us 14:29:21 in contrast to action=enqueue::port 14:29:32 which had to be only in the output action (final rule) 14:29:44 and it was hard to integrate for example with "NORMAL" rules 14:29:55 where the switch decides the output port based on his arp tables 14:30:17 I checked it, 14:30:19 and it works 14:30:29 haleyb: thanks for caring about stable 14:30:31 oops 14:30:36 wrong channel 14:30:36 so, it should be rather easy to implement now in OVS / openflow :) 14:30:46 I thank haleyb too :D (lol) :) 14:30:58 * njohnston applauds haleyb 14:31:13 we may need somebody to look at how to implement min bw guarantees in linuxbridge if that's possible 14:31:18 also, 14:31:36 * haleyb is just doing his job 14:31:40 there's a 2nd step of such RFE (probably needs to be addressed later), which is, integrating with nova scheduling :) 14:32:01 they're working on the generic pools , which we may eventually leverage when it's ready 14:32:15 but there are still some incognitas 14:32:30 I'm talking about: 14:32:34 #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html 14:33:07 #action ajo send an email to openstack-dev talking about this topic 14:33:37 We need to provide feedback to resource-providers-scheduler ... to make sure we find a good method for the nova scheduler 14:33:44 to make interpretations out of our ports & policies 14:33:57 to determine the min-bw requirements, necessary for strict min-bw scheduling 14:34:28 ihrachys and I believe the interpretation of such things may not correspond to nova, and may be the thing could be pluggable 14:34:48 so we could provide something to pull the right objects from neutron, and make a good interpretation of the port 14:34:55 another approach, could be 14:35:13 ( ihrachys correct me if I got you wrong, of course, ^ ) 14:35:22 ajo: I will correct you on the email :P 14:35:28 lol :) 14:35:30 ajo: but it seems ok 14:35:35 another approach to this 14:35:54 could be... neutron makes the interpretation on a "port read" or "port create with a policy"... and returns a field with the min-bw required 14:36:02 so nova does not need to call us back, or get a policy, or anything 14:36:09 but I'm not sure about how restful that is 14:36:34 we may need to discuss such thing with the community, or salvatore (api-wg contact point) 14:37:57 ok 14:39:02 anybody wants to mention any of the other RFEs / any update on them? 14:39:57 Well... want to know the next step 14:40:04 #link https://bugs.launchpad.net/neutron/+bug/1505627 14:40:15 reedip__: Error: Could not gather data from Launchpad for bug #1505627 (https://launchpad.net/bugs/1505627). The error has been logged 14:40:37 Why do weird things happen with me ?? 14:40:44 :) 14:40:58 :) 14:41:22 jeje 14:41:23 hehe 14:41:36 ajo : spec can be started once confirmation from drivers team is obtained 14:41:43 I'm not sure reedip__ we may need to answer amotoki's question 14:41:52 that would probably help amotoki's answers as well 14:42:17 I will talk to him about this RFE, and see where we go 14:42:44 #action discuss https://bugs.launchpad.net/neutron/+bug/1505627 with amotoki, and provide the high level details 14:42:46 Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Confirmed] - Assigned to Reedip (reedip-banerjee) 14:42:53 ok, then I will go the other way round, answering amotoki's questions first and then progressing forward.... 14:43:04 said that, I'm not sure the high level details were clear after our last conversation 14:43:05 see... It worked when you typed... Launchpad hates me 14:43:16 may be we could ask them for permission to work on a more detailed spec 14:43:26 so we can clarify top/down of it 14:43:29 ajo : maybe 14:43:43 bug comments become to messy .. ':D 14:43:55 but they are currently more concerned about high level view 14:44:14 reediip__ of course, that's the first thing that needs to be clear 14:44:30 reedip__ you could provide a use case, of how to setup the rules exactly 14:44:36 and how those would work 14:44:43 Ok, I will put up my response in the etherpad , along with some possible use cases 14:44:58 some detail looks good but i could not capture what kind of features are exposed honestly 14:45:04 amotoki has put up these questions on etherpad as well, so I think we can start modelling it as a spec 14:45:16 reedip__ if you can put on the rfe summary something like the neutron cli rule creations, etc.. 14:45:23 and the expected behaviour of the set rules 14:45:25 that may help too 14:45:56 Oka... 14:46:08 (note that meeting bot seems in some trouble during the last week meeting.... no log...) 14:46:18 hmmm 14:46:21 yikes :/ 14:46:32 may be I used a wrong meeting id? 14:46:33 amotoki: means I need to copy this stuff after the eeting ends 14:46:34 I will check my logs 14:46:36 (no log around ECN dsicussion) 14:46:52 I see logs: http://eavesdrop.openstack.org/meetings/neutron_qos/2016/neutron_qos.2016-04-06-14.02.log.txt 14:47:11 #addchair ihrachys 14:47:16 does it work like that? :) 14:47:28 I need to leave and I see there could be conversation here about ECN 14:47:35 njhonston is right.. logs are being generated 14:48:14 #chair ihrachys 14:48:15 Current chairs: ajo ihrachys 14:48:25 #chair amotoki 14:48:26 Current chairs: ajo amotoki ihrachys 14:48:28 #chair njohnston 14:48:29 Current chairs: ajo amotoki ihrachys njohnston 14:48:39 musical chairs... 14:48:40 * njohnston is honored 14:48:42 guys, can you #endmeeting once this is over? :) 14:48:45 ??? what's happening 14:48:46 I need to leave 14:48:47 sure thing 14:48:52 thanks 14:48:57 see http://eavesdrop.openstack.org/meetings/neutron_qos/2016/neutron_qos.2016-03-23-14.03.log.html 14:49:09 ajo: ? I am not sure what you mean. you leave us in the middle of the thing? 14:49:21 log jumps 14:08:24 to 14:24:02 in the meeting log Mar 23... 14:49:38 amotoki: That is not the log for today (4/6), that is the log for 3/23. 14:49:46 ajo: just stop the meeting if we loose a chair. I am not in position to lead it. 14:50:04 I can lead it. 14:50:05 yes. I tried to caputre the discussion mentioned in the rfe bug discussed now. 14:50:07 amotoki: means that there is about 16 mins of log missing it appears 14:50:18 yup... 14:50:32 sorry for disturb. go ahead 14:50:38 Thankfully I have logs to my disk :) 14:51:12 anyways, so as discussed with ajo regarding the ECN bug, I will respond to amotoki's questions, present some possible use cases 14:51:24 and expected behavior 14:51:24 Are there any other RFEs to discuss? 14:51:39 not from my side... 14:52:02 OK, then let's move on to open discussion 14:52:03 #topic Open Discussion 14:52:19 Does anyone have anything else they would like to discuss? 14:52:32 Do we have a session ( fishbowl or other) decided yet ? 14:52:37 in Austin summit? 14:52:46 just a query off the top of my head 14:52:49 https://etherpad.openstack.org/p/newton-neutron-summit-ideas 14:53:07 line 21, has 3 topics for discussion 14:53:14 davidsha ; yeah I saw that earlier today :) 14:53:33 Yes, QoS has an entry in the list, but I haven't seen any announcement from armax on what ideas will be assigned to the available session slots. 14:54:01 That being said, I think there is enough interest in QoS that I feel confident we will get one of the sessions. 14:54:06 okay ... just what I wanted to know 14:54:55 nothing else... thanks 14:55:02 Is there anyone working on something at the moment that uses Openflows actually? I have an entry for discussing flow management and I'm interested in more use cases. 14:55:31 davidsha: Is tmorin working on something in the networking-bgpvpn space? 14:55:38 I know he reached out to you. 14:56:22 njohnston: ya, I was talking to him. he said he'd be interested in coming to it. just trying to deploy bgpvpn atm! 14:56:37 davidsha: sfc? 14:57:47 Well, we are almost out of time, does anyone have anything else they would like to raise? 14:58:05 ihrachys: I was talking to someone from sfc but they may have stepped back from the community, I'll ask some more. there is tap-aas as well but sfc and t-aas haven't implemented the l2-agent api yet 14:58:45 Thanks! 14:58:52 davidsha: that's probably something to consider when (not) keeping them in stadium 14:59:03 +1 to that 14:59:04 davidsha: they should be expected to consume best practices from core 14:59:28 davidsha : taas l2-agent api is my AI :) 14:59:35 AI == ? 14:59:36 would be great if you can give some tips 14:59:40 Action Item 14:59:42 ack 14:59:46 I am helping TaaS... 14:59:49 reedip: Excellent! 15:00:09 All right, I have to call time. 15:00:11 time! 15:00:11 #endmeeting