18:02:15 <sc68cal> #startmeeting neutron_qos
18:02:16 <openstack> Meeting started Tue Jun  3 18:02:15 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:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
18:02:19 <openstack> The meeting name has been set to 'neutron_qos'
18:02:48 <sc68cal> I haven't started building agendas for the meeting just yet, I also need to make a wiki page for us
18:03:05 <sc68cal> so for now we'll keep it pretty free form until we settle into a rhythm
18:03:30 <sc68cal> I know nati_uen_ has some stuff to share
18:03:38 <nati_uen_> yes
18:03:51 <nati_uen_> Can I share it now?
18:03:58 <nati_uen_> or do you guys have another topics?
18:04:44 <sc68cal> anyone have any other topics they want to share?
18:05:22 <nati_uen_> ok, so let me share mine
18:05:29 <nati_uen_> I'm working on Action support for security group
18:05:35 <nati_uen_> BP --> https://review.openstack.org/#/c/93112/
18:05:48 <nati_uen_> My idea is specify qos apply rule in security group as an action
18:06:13 <nati_uen_> so In current QoS BP, we can apply qos resource for port and network
18:06:28 <nati_uen_> In addition to this, I would like to apply qos for security groups
18:06:46 <nati_uen_> because it is same in most of application deployment
18:06:53 <nati_uen_> For example, web3tier app
18:07:09 <nati_uen_> We will have, web security group, app security group and db security group
18:07:24 <nati_uen_> They will have different security filtering policy.
18:07:39 <nati_uen_> I believe QoS configuration overwraps this grouping
18:07:40 <aveiga> nati_uen_: are you proposing a method to add QoS to Egress rules? For instance, being able to do EF and AF to RTP and SIP, respectively?
18:08:08 <nati_uen_> aveiga: yes. we can specify it engress or igress
18:08:14 <aveiga> :)
18:08:19 <nati_uen_> i'm not sure all driver may support it..
18:08:51 <sc68cal> So - we could use the existing match criteria the sec group exposes (like port ranges)
18:09:05 <sc68cal> then just use the QoS api to store the mark that it would apply?
18:09:15 <nati_uen_> yes
18:09:27 <sc68cal> cool - less work for me :)
18:09:29 <nati_uen_> What I'm thinking is to use qos resources
18:09:37 <sc68cal> instead of making drivers that do port ranges
18:09:38 <nati_uen_> ya hopefully :)
18:09:52 <nati_uen_> We can also reuse existing security group rpc internally
18:10:30 <nati_uen_> https://github.com/openstack/neutron/blob/master/neutron/db/securitygroups_rpc_base.py#L353
18:10:37 <sc68cal> yeah, cut down on some of the RPC methods the qos api extension required
18:10:44 <nati_uen_> We can mix def from QoS policy in the code here
18:10:48 <nati_uen_> yes
18:11:08 <kevinbenton_> so a security group rule would just reference a policy as an action, right?
18:11:19 <nati_uen_> yes
18:11:50 <nati_uen_> L214 https://review.openstack.org/#/c/93112/14/specs/juno/security_group_action.rst <--
18:12:00 <sc68cal> so another thing I wanted to make sure was still ok, was doing QoS policies per port and network, since that affects other implementations, like kevinbenton_
18:12:22 <nati_uen_> yes. IMO, we may have two way
18:12:33 <sc68cal> perfect. :)
18:12:39 <kevinbenton_> sounds good
18:12:53 <nati_uen_> OK Thanks. Let's collaborate on this
18:13:06 <kevinbenton_> so actually if the reference is from the security group side, what do you need on the qos db side?
18:13:36 <sc68cal> I think the security group action would reference the qos_id
18:13:44 <nati_uen_> if you like spec, let me do some poc work
18:13:57 <nati_uen_> I don't think it will impact qos design
18:14:01 <nati_uen_> on API
18:14:10 <nati_uen_> rcp part may be simplifed
18:14:26 <nati_uen_> I tried to make it working till this meeting, but it looks like need some more time
18:14:59 <sc68cal> no worries
18:15:11 <nati_uen_> hopefully, I could share the poc in next meeting
18:16:02 <sc68cal> cool
18:16:17 <nati_uen_> ok that is all from me
18:16:35 <sc68cal> I have some work to do on the DB side for the qos API, so I'll be updating my review in time for next meeting too
18:16:43 <nati_uen_> OK
18:16:44 <kevinbenton_> nati_uen_ that sounds good
18:16:48 <nati_uen_> kevinbenton_: Thanks
18:17:03 <nati_uen_> it is great if we could remove WIP in qos bp
18:17:05 <sc68cal> most likely it'll still be WIP, but I'll try and address some reviewer comments and other things
18:17:11 <s3wong> sc68cal: would you mind posting a link to your review (so far)?
18:17:31 <sc68cal> s3wong: https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/ml2-qos,n,z
18:17:37 <nati_uen_> https://review.openstack.org/#/c/88599/
18:17:39 <s3wong> sc68cal: thanks
18:17:56 <sc68cal> boy are gerrit reviews ugly.
18:18:33 <sc68cal> I'll also update the spec from the comments people posted. Which by the way, thanks!!
18:18:48 <kevinbenton_> trailing whitespaces!
18:18:57 <sc68cal> and /qoses.json :)
18:19:00 <nati_uen_> he he
18:19:14 <sc68cal> I am really convinced that the neutron-spec is a Good Thing
18:19:26 <nati_uen_> ya
18:19:26 <sc68cal> because the QOS api extension stuff was just all. over. the. place.
18:19:32 <sc68cal> mailing list, launchpad, commit messages.....
18:19:41 <kevinbenton_> ®
18:20:00 * nati_uen_ wondering how kevin input the magic word
18:20:26 <kevinbenton_> had to google it, that’s why i was too slow to get it right after Good Thing®
18:20:43 <nati_uen_> "Good Thing®" ha ha ha
18:20:43 <sc68cal> Good Thing™
18:20:53 <nati_uen_> ♫
18:21:20 <nati_uen_> so all topic is covered?
18:21:47 <sc68cal> I think so - I'll just switch to open discussion since I don't have a real agenda yet :)
18:21:53 <sc68cal> #topic open discussion
18:22:08 <nati_uen_> so ref impl is ovs based, right?
18:22:16 <sc68cal> correct
18:22:21 <nati_uen_> ok
18:22:28 <nati_uen_> so ml2 + ovs mech driver
18:22:31 <nati_uen_> support it
18:22:45 <nati_uen_> how we specify directions?
18:22:46 <sc68cal> yes - and there is a ml2 + lb mech impl for ratelimit
18:22:54 <nati_uen_> ok
18:23:00 <nati_uen_> ingress only?
18:23:03 <kevinbenton_> the reference won’t be able to rate limit, just tag, right?
18:23:09 <sc68cal> I think egress
18:23:16 <nati_uen_> ok
18:23:28 <nati_uen_> Can we use it in virtual router?
18:23:29 <sc68cal> https://review.openstack.org/96331
18:23:49 <nati_uen_> ok Thanks
18:23:53 <sc68cal> I would imagine so, tag the virtual router's port with a rate-limit policy
18:24:17 <nati_uen_> so someone will apply rate limit by tag?
18:24:35 <sc68cal> unsure
18:24:49 <sc68cal> do you mean by .1q tag?
18:25:41 <nati_uen_> ah may be I don't understand the meaning of "just tag"
18:25:48 <sc68cal> Ahhhh
18:25:50 <sc68cal> ok I mean like
18:25:51 <s3wong> sc68cal: .1p is priority tagging, if I remember correctly?
18:26:04 <sc68cal> neutron port-update <router port ID> --qos <ratelimit policy ID>
18:26:10 <sc68cal> sorry for the confusion
18:26:36 <s3wong> sc68cal: what is the definition of ratelimit policy?
18:27:05 <s3wong> (sorry, too lazy to look up now...)
18:27:05 <sc68cal> fairly basic
18:27:09 <sc68cal> https://review.openstack.org/#/c/88599/3/specs/juno/qos-api-extension.rst
18:27:16 <sc68cal> line.... 80
18:27:41 <sc68cal> but I think I need to coordinate with the Linuxbridge ratelimit spec author to verify
18:27:55 <s3wong> OK. kbps
18:28:16 <sc68cal> https://review.openstack.org/#/c/96331/4/specs/juno/ml2-qos-linuxbridge.rst
18:31:11 <nati_uen_> ok so any other topics?
18:31:20 <kevinbenton_> nothing from me
18:31:36 <nati_uen_> me too
18:31:43 <s3wong> I am interested in QoS due to group-policy policy-rule action
18:32:07 <s3wong> but will have to look at the current proposal to better understood how we can utilize this
18:32:25 <sc68cal> Currently, I think GP is going to consume the qos API
18:32:50 <sc68cal> or at least the hope is to minimize duplication by having the GP drive the qos API
18:33:24 <s3wong> sc68cal: sounds good - quite honestly we don't yet have any definition on how to set QoS as action
18:33:48 <s3wong> but utilizing the qos API directly is a good plan
18:35:24 <sc68cal> Anything else? I can give everyone back half an our
18:35:25 <sc68cal> *hour
18:35:36 <s3wong> all good
18:35:49 <sc68cal> I'll make a subteam wiki page so we can start building agendas for things people want to talk about :)
18:35:59 <sc68cal> #action sc68cal make a subteam wiki page
18:36:06 <s3wong> sounds great
18:36:18 <sc68cal> OK then everyone, thanks for joining, see everyone next week!
18:36:26 <sc68cal> #endmeeting