14:02:59 <moshele> #startmeeting neutron_qos 14:02:59 <openstack> Meeting started Wed Jan 6 14:02:59 2016 UTC and is due to finish in 60 minutes. The chair is moshele. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:03:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:03:02 <openstack> The meeting name has been set to 'neutron_qos' 14:03:11 <moshele> hi everone 14:03:21 <ihrachys> o/ 14:03:33 <moshele> ajo is still on PTO so I will replace him today 14:04:01 <irenab> moshele: I do no think anyone can replace ajo :-) 14:04:07 <ihrachys> I guess we want to focus on whatever is on https://etherpad.openstack.org/p/qos-mitaka 14:04:21 <moshele> irenab: I gess you right :) 14:04:26 <moshele> yes 14:04:27 * ihrachys just walked thru it several minutes before the meeting, updated a bit 14:04:51 <moshele> so I know that ajo is working on the upgrade patches 14:05:07 <ihrachys> I guess it's not uploaded yet, I haven't seen any 14:05:12 <ihrachys> devref is merged, but that's it 14:05:41 <moshele> he said he will upload it on the 8th 14:05:43 <moshele> I think 14:05:54 <ihrachys> he is an optimistic guy ;) 14:06:03 <ihrachys> we'll see 14:06:33 <moshele> RBAC spec already one +2 14:06:40 <moshele> so I guess it close to merge 14:06:42 <ihrachys> hdaniel: ^ 14:06:54 <ihrachys> moshele: spec, yeah. code wise, I guess we still have stuff to tinker 14:07:05 <ihrachys> but the patch is up for some time: https://review.openstack.org/#/c/250081/ 14:07:39 <ihrachys> it may actually work, but there are some concerns to clear around code decomposition 14:07:42 <moshele> and it has -1 14:07:55 <ihrachys> four -1s :) 14:08:16 <moshele> is hdaniel here? 14:08:20 <hdaniel> yep 14:08:38 <hdaniel> the code cleanups are mostly done - one issue still unresolved - need ihrachys for that 14:09:03 <hdaniel> but that might require a complete code reshuffle 14:09:10 <ihrachys> hdaniel: yeah, let's schedule a chat for this week, f.e. tomorrow, so that we can clear it. 14:09:23 <hdaniel> ihrachys: sounds solid to /me 14:09:34 <ihrachys> hdaniel: not complete! just around 80% maybe! 14:10:34 <moshele> let move to the Linux bridge rate limite 14:10:38 <ihrachys> yeah! 14:10:45 <moshele> is slaweq here? 14:10:46 <ihrachys> I don't see Slawek here 14:11:02 <ihrachys> but anyway, I can probably update 14:11:11 <moshele> go head 14:11:12 <ihrachys> so extension manager support is finally in gate or merged: https://review.openstack.org/#/c/250542/ 14:11:26 <ihrachys> Slawek will need to rebase his patch for LB qos on top of it. 14:11:51 <ihrachys> also I believe there is some work to do for fullstack framework here: https://review.openstack.org/#/c/248938/ 14:11:57 <ihrachys> which is a blocker for the qos patch 14:12:07 <ihrachys> for what I wonder, Slawek is actively looking at both 14:12:15 <ihrachys> that's it 14:12:52 <moshele> cool I will add the fullstack patch to etherpad 14:13:04 <ihrachys> it's there I think 14:13:14 <moshele> yes I just saw it :) 14:13:30 <moshele> moving to DSCP Markings 14:14:23 <moshele> I didn't see mach activity there 14:14:35 <ihrachys> yeah. also it has two dependencies 14:14:56 <ihrachys> one is upgrade thing from ajo, another one the agent uuid for graceful restart from me 14:14:57 <davidsha> No, we're waiting on the l2 agent extension api 14:15:11 <ihrachys> #link https://review.openstack.org/#/c/263819/ 14:15:24 <davidsha> Ya ^ 14:15:31 <ihrachys> ^ that's the spec for phase1 of my ovs proposal that will allow to unblock qos 14:15:36 <ihrachys> just exposing uuid 14:15:56 <ihrachys> and then I will be able to work on remaining table rework in my pace 14:16:35 <ihrachys> I plan to start coding the bits this week 14:17:03 <moshele> I will review the l2 agent extension api spec 14:17:59 <ihrachys> thanks. it's tiny. 14:18:13 <moshele> anything else on the DSCP Markings 14:18:15 <moshele> ? 14:18:31 <davidsha> No, not at the moment 14:18:48 <davidsha> Thanks. 14:19:14 <moshele> let move to bugs 14:19:31 <moshele> I didn't see any new bug regrading qos 14:20:02 <irenab> I added rfe (ajo asked me before he went to PTO) 14:20:17 <irenab> https://bugs.launchpad.net/neutron/+bug/1531485 14:20:18 <openstack> Launchpad bug 1531485 in neutron "Available device bandwidth report by L2 agent" [Undecided,New] 14:20:56 <davidsha> I submitted a rfe for priority queueing https://bugs.launchpad.net/neutron/+bug/1527671 14:20:57 <openstack> Launchpad bug 1527671 in neutron "Neutron QoS Priority Queuing rule" [Wishlist,Confirmed] 14:21:06 <ihrachys> irenab: well, that one probably also depends on agent API 14:21:42 <ihrachys> because you would need some way to pass data from extension into the agent. 14:21:52 <irenab> ihrachys: I will check the API, but I think its just adding more content to the agent report status 14:22:14 <moshele> irenab: how you plane to report the physical device bandwidth information for OVS? it know only the bridges 14:22:19 <ihrachys> irenab: yeah, but how would your extension talk to the agent? currently it's completely stateless for what agent cares. 14:22:40 <ihrachys> moshele: underlying physical devices? 14:23:08 <moshele> yes 14:23:26 <irenab> both SR-IOV and OVS had mappings to physical devices, so it should be quite easy 14:23:59 <irenab> ihrachys: Will check your spec to see what will it require to pass details to the agent 14:24:15 <ihrachys> not much, just another agent API for just that. 14:24:51 <ihrachys> not sure I love passing it through state reports, but I haven't thought it through yet to comment. 14:24:55 <irenab> there was some bug reported by vikram on netowrk policy repurposing 14:26:11 <irenab> ihrachys: I do not have any strong preferences 14:26:37 <irenab> https://bugs.launchpad.net/neutron/+bug/1521194 14:26:38 <openstack> Launchpad bug 1521194 in neutron "Qos Aggregated Bandwidth Rate Limiting" [Wishlist,Triaged] 14:27:10 <irenab> ihrachys: would be great if you can check this 14:27:22 <moshele> yes so what I didn't understand for his spec is how he plane to implement it 14:27:54 <moshele> so there will be to behaviors to network qos 14:27:59 <irenab> I think we first need to agree on the problem he solves :-) 14:28:17 <ihrachys> irenab: ack, adding to todo 14:28:48 <irenab> He suggested to change the existing network -policy association meaning 14:29:09 <moshele> I understood the he want to support both cases 14:29:09 <ihrachys> well, you could just divide it to the number of ports :), but that's not what we probably want 14:29:19 <ihrachys> irenab: api change? meh 14:29:45 <irenab> ihrachys: not the api change, but change of the current intention 14:30:38 <moshele> let say you have 20GB network and 10 vm so each vm will get 2 GB 14:30:43 <ihrachys> hm, I did not know that we intended to do aggregation before 14:30:59 <ihrachys> where was the intent captured? 14:31:00 <irenab> I think its new 14:31:16 <davidsha> It was brought up last meeting 14:31:23 <davidsha> about 4 weeks ago 14:31:43 <ihrachys> the way we designed it, it was always 'the default value to apply to port if no port level policy is attached'. if it's documented in another way, we should fix the docs 14:31:58 <irenab> ihrachys: I think vikram documented it well on this bug report. Let’s see what would be the best way to handle it 14:32:15 <ihrachys> ok, I will check it later with more attention 14:32:21 <irenab> ihrachys: agree, need to verify the documentation 14:34:20 <ihrachys> moshele: should we move? 14:34:29 <moshele> yes sorry 14:34:39 <moshele> I think we are done 14:34:52 <moshele> anyone has anything to add ? 14:35:06 <ihrachys> not me 14:35:12 <irenab> no 14:35:47 <moshele> ok thanks everyone 14:35:49 <moshele> #endmeeting