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