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