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