18:02:32 #startmeeting neutron_qos 18:02:33 Meeting started Tue Jun 10 18:02:32 2014 UTC and is due to finish in 60 minutes. The chair is sc68cal. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:02:34 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 18:02:38 The meeting name has been set to 'neutron_qos' 18:02:43 #link https://wiki.openstack.org/wiki/Meetings/NeutronQoS 18:03:12 So, I did create a wiki page for the subteam :) 18:03:47 sc68cal: wow, loads of stuff :-) 18:03:51 :) 18:04:37 I could run an agenda similar to the IPv6 subteam, but I don't want to dictate to people what the agenda is 18:04:47 blueprints, code reviews, bugs, open discussion 18:05:00 I imagine we 18:05:06 would skip over bugs for now :) 18:05:24 sc68cal: got to have code first before bugs :-) 18:05:41 I was planning on it being perfect the first time :-p 18:05:57 and then vehemently denying the existince of bugs ;) 18:06:26 #topic blueprints 18:06:38 #link https://review.openstack.org/#/c/88599/3/specs/juno/qos-api-extension.rst 18:06:54 So, I have to apologize to everyone for the lack of updates to that spec 18:07:16 J-1 is this week so I've been trying to get some ipv6 patches landed 18:07:46 sc68cal: and I haven't reviewed the spec yet neither, so I also have to apologize 18:08:19 for J-2 I will be doing support, rather than dev on the ipv6 side so I've allocated my sprints towards the QoS API for the J-2 timeframe. I recognize that I'm currently the SPOF for the spec, and I want to get out of the way and unblock people 18:09:26 cool 18:12:01 Really that's all I have to report, the fact that I recognize I'm the SPOF for the spec currently and asking for a little more time to sort things out on the v6 side. It's not the best situation, so I plan on trying to delegate more things to people in the future 18:12:31 OK 18:13:08 I'm hoping that we might be able to get things considered for J-2 or J-3, though I'll have to talk to mestery and see. 18:13:39 sc68cal: Ready and waiting for that discussion. :) 18:13:44 Hahah :) 18:14:05 sc68cal: yes. Since we are just having rate-limiting and DSCP marking, it seems simple enough to have hope for Juno timeframe 18:14:59 Nova parity is a big item for the J release, so I prefer to underpromise and over-deliver, rather than the inverse 18:15:18 sc68cal: certainly :-) 18:15:47 Just noticed that DVR won't make J-1, and is pushed out to J-2 18:16:48 so more stress on core-dev for reviews in later phases... 18:16:49 yeah - my heart goes out to the people on DVR. :) 18:17:44 That's about all I have on the blueprint side, unless we want to discuss the ratelimit spec 18:18:02 #link https://review.openstack.org/96331 18:18:29 Linux bridge? 18:18:56 s3wong: yeah, the first concrete implementation of the ratelimit type will be via the linuxbridge mech driver 18:19:43 sc68cal: I see. This will utilize the API you have on the API spec 18:20:23 s3wong: correct - I just need to update one section of my spec to reflect some of the policy keys the LB ratelimit requires 18:20:47 since they want keypairs that correspond to the tc command args, I believe 18:21:31 sc68cal: while we should satisfy tc command use case, should we really model the API after whta tc needs? 18:22:43 s3wong: a valid concern 18:23:24 I would suggest asking that in either my spec or the linuxbridge spec 18:23:31 to capture that concern 18:23:38 sc68cal: sure 18:24:03 My thinking is that we would start off just validating the args for a ratelimit policy with tc in mind as the target 18:24:35 sc68cal: yes, certainly we have to ensure it works for the first reference implementation 18:24:47 but when another implementation comes along, try an agree on overlapping keypairs can be validated by common code 18:25:05 then have a way to validate the extra keypairs for each implementation 18:25:10 it might end up creating different types 18:25:14 ratelimit-linuxbridge 18:25:27 ratelimit-next 18:25:57 sc68cal: creating a flavor framework for QoS :-) 18:26:21 s3wong: good point, or hoping that we can piggy back on the flavor framework that is being discussed 18:27:01 sc68cal: that would be interesting. Now the flavor framework is tags used to describe class of network services 18:27:36 Sounds like we have some wiggle room with that wording to sneak in :) 18:28:22 sc68cal: though the tags are more associated with the service driver (who it advertises) vs which network / connectivity driver to use 18:28:40 (I assume it would be the network / connectivity driver who is going to provide QoS 18:30:26 Yeah currently qos is a driver that is set in the agent configuration 18:30:50 at least for the ml2 plugin and ovs agent combo 18:31:20 sc68cal: yes 18:33:56 That's about all I have for today, I can give everyone back half an hour if there is nothing else 18:34:04 sc68cal: +1 18:34:12 I'm always in #openstack-neutron too, so don't be a stranger :) 18:34:39 s3wong: thanks for coming, good stuff! 18:34:47 sc68cal: thanks! 18:34:48 #endmeeting