18:02:32 <sc68cal> #startmeeting neutron_qos
18:02:33 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:38 <openstack> The meeting name has been set to 'neutron_qos'
18:02:43 <sc68cal> #link https://wiki.openstack.org/wiki/Meetings/NeutronQoS
18:03:12 <sc68cal> So, I did create a wiki page for the subteam :)
18:03:47 <s3wong> sc68cal: wow, loads of stuff :-)
18:03:51 <sc68cal> :)
18:04:37 <sc68cal> 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 <sc68cal> blueprints, code reviews, bugs, open discussion
18:05:00 <sc68cal> I imagine we
18:05:06 <sc68cal> would skip over bugs for now :)
18:05:24 <s3wong> sc68cal: got to have code first before bugs :-)
18:05:41 <sc68cal> I was planning on it being perfect the first time :-p
18:05:57 <sc68cal> and then vehemently denying the existince of bugs ;)
18:06:26 <sc68cal> #topic blueprints
18:06:38 <sc68cal> #link https://review.openstack.org/#/c/88599/3/specs/juno/qos-api-extension.rst
18:06:54 <sc68cal> So, I have to apologize to everyone for the lack of updates to that spec
18:07:16 <sc68cal> J-1 is this week so I've been trying to get some ipv6 patches landed
18:07:46 <s3wong> sc68cal: and I haven't reviewed the spec yet neither, so I also have to apologize
18:08:19 <sc68cal> 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 <s3wong> cool
18:12:01 <sc68cal> 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 <s3wong> OK
18:13:08 <sc68cal> 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 <mestery> sc68cal: Ready and waiting for that discussion. :)
18:13:44 <sc68cal> Hahah :)
18:14:05 <s3wong> 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 <sc68cal> 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 <s3wong> sc68cal: certainly :-)
18:15:47 <s3wong> Just noticed that DVR won't make J-1, and is pushed out to J-2
18:16:48 <s3wong> so more stress on core-dev for reviews in later phases...
18:16:49 <sc68cal> yeah - my heart goes out to the people on DVR. :)
18:17:44 <sc68cal> That's about all I have on the blueprint side, unless we want to discuss the ratelimit spec
18:18:02 <sc68cal> #link https://review.openstack.org/96331
18:18:29 <s3wong> Linux bridge?
18:18:56 <sc68cal> s3wong: yeah, the first concrete implementation of the ratelimit type will be via the linuxbridge mech driver
18:19:43 <s3wong> sc68cal: I see. This will utilize the API you have on the API spec
18:20:23 <sc68cal> 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 <sc68cal> since they want keypairs that correspond to the tc command args, I believe
18:21:31 <s3wong> sc68cal: while we should satisfy tc command use case, should we really model the API after whta tc needs?
18:22:43 <sc68cal> s3wong: a valid concern
18:23:24 <sc68cal> I would suggest asking that in either my spec or the linuxbridge spec
18:23:31 <sc68cal> to capture that concern
18:23:38 <s3wong> sc68cal: sure
18:24:03 <sc68cal> 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 <s3wong> sc68cal: yes, certainly we have to ensure it works for the first reference implementation
18:24:47 <sc68cal> but when another implementation comes along, try an agree on overlapping keypairs can be validated by common code
18:25:05 <sc68cal> then have a way to validate the extra keypairs for each implementation
18:25:10 <sc68cal> it might end up creating different types
18:25:14 <sc68cal> ratelimit-linuxbridge
18:25:27 <sc68cal> ratelimit-next
18:25:57 <s3wong> sc68cal: creating a flavor framework for QoS :-)
18:26:21 <sc68cal> s3wong: good point, or hoping that we can piggy back on the flavor framework that is being discussed
18:27:01 <s3wong> sc68cal: that would be interesting. Now the flavor framework is tags used to describe class of network services
18:27:36 <sc68cal> Sounds like we have some wiggle room with that wording to sneak in :)
18:28:22 <s3wong> sc68cal: though the tags are more associated with the service driver (who it advertises) vs which network / connectivity driver to use
18:28:40 <s3wong> (I assume it would be the network / connectivity driver who is going to provide QoS
18:30:26 <sc68cal> Yeah currently qos is a driver that is set in the agent configuration
18:30:50 <sc68cal> at least for the ml2 plugin and ovs agent combo
18:31:20 <s3wong> sc68cal: yes
18:33:56 <sc68cal> That's about all I have for today, I can give everyone back half an hour if there is nothing else
18:34:04 <s3wong> sc68cal: +1
18:34:12 <sc68cal> I'm always in #openstack-neutron too, so don't be a stranger :)
18:34:39 <sc68cal> s3wong: thanks for coming, good stuff!
18:34:47 <s3wong> sc68cal: thanks!
18:34:48 <sc68cal> #endmeeting