14:00:00 <njohnston_> #startmeeting neutron_qos
14:00:00 <njohnston_> #chair ajo
14:00:00 <njohnston_> Good day everyone!
14:00:01 <openstack> Meeting started Wed Aug 10 14:00:00 2016 UTC and is due to finish in 60 minutes.  The chair is njohnston_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:02 <njohnston_> #link https://etherpad.openstack.org/p/neutron_qos_meeting_chair for the meeting agenda
14:00:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:06 <openstack> The meeting name has been set to 'neutron_qos'
14:00:07 <openstack> Current chairs: ajo njohnston_
14:00:09 <davidsha> Hey!
14:00:25 <ajo> hi njohnston_  :D
14:00:30 <ajo> hi slaweq , davidsha
14:00:33 <slaweq> hello
14:00:37 <ajo> ihrachys, we'll ping you eventually ;D
14:00:41 <njohnston_> Hello davidsha, ajo, slaweq
14:01:03 <ajo> ralonsoh, ping :)
14:01:31 <ihrachys> ajo: we should sit one on one and talk about qos reviews if you want me to help. otherwise I am of no use.
14:01:40 * njohnston_ waits a minute for ralonsoh
14:01:49 <davidsha> ralonsoh will be along shortly
14:02:16 <njohnston_> OK, I'll defer some of the ralonsoh stuff, but let's get started.
14:02:17 <ajo> ihrachys, ack, I'll 1:1 with you for a couple of them I think need your oversight
14:02:22 <njohnston_> #topic RFEs
14:02:35 <njohnston_> #link https://bugs.launchpad.net/neutron/+bug/1586056
14:02:35 <openstack> Launchpad bug 1586056 in neutron "[RFE] Improved validation mechanism for QoS rules with port types" [Wishlist,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:02:35 <njohnston_> #link https://review.openstack.org/#/c/319694/
14:02:35 <njohnston_> Validation change - how goes it?
14:02:50 <ralonsoh> sorry for the delay
14:02:58 <slaweq> it's not going :/
14:03:26 <njohnston_> I haven't been keeping track, what is going on?
14:03:29 <ajo> slaweq, has been working in that with good progress, but may need this bit to avoid weirdnesses on the model: https://review.openstack.org/#/c/351858/
14:03:30 <slaweq> ajo can explain more details but there are some issue with "design" of notifications
14:03:42 <ihrachys> because we have qos driver from ajo refactoring to do, right?
14:03:57 <ajo> ihrachys, I may need your help having a look on that one ^ (moving notification_driver to qos_driver with "get_os_driver")
14:04:00 <njohnston_> #link https://review.openstack.org/#/c/351858/  That is where this comes in, yes?
14:04:04 <ihrachys> ajo: I haven't paid attention. Why is it WIP and is armax on board?
14:04:27 <ajo> ihrachys, because it's similar to what he's doing with trunk port service, but on a different way
14:04:46 <ajo> we both agreed to proceed on probably diverging paths, but to review the final results, and then converge back to one single path
14:04:47 <njohnston_> I am very interested in this because FWaaS is copying this model in part.
14:04:52 <ihrachys> ajo: does he use callbacks for that?
14:05:14 <ajo> ihrachys, yes, mostly, but there are drawbacks to that IMO, and some benefits, of course
14:05:29 <ihrachys> ok, let's discuss it when you will enlighten me
14:05:54 <ajo> we have another 1:1 set with him next week to talk about this topic again to check our progresses
14:06:06 <ajo> njohnston_, basically, we realised that in the case of dos,
14:06:08 <ajo> arghh
14:06:15 <ajo> I have an auto corrector, let me disable it (qos->dos)
14:06:35 <ajo> disabled
14:06:37 <ajo> ':)
14:06:53 <njohnston_> http://www.extremetech.com/wp-content/uploads/2011/07/2000px-StartingMsdos2.jpg
14:06:55 <ajo> basically, we realized different things
14:07:01 <ajo> lol
14:07:21 <ajo> 1) the QoS "notification" driver, needs to evolve beyond notifications, it's actually a driver
14:07:34 <ajo> also, notifications are used in the context of ceilometer, etc, those are different things.
14:07:55 <ajo> 2) the concept of having multiple qos backend drivers (now notification drivers) is coupled to the concept of ML2
14:08:16 <ajo> where we have different mechanism drivers, which potentially can have different backend, and communication mechanisms
14:08:27 <ajo> so in https://review.openstack.org/#/c/351858/
14:08:39 <ajo> we rename QoSNotificationDriver into QosDriver,
14:08:40 <ajo> and
14:08:56 <ajo> instead of having a config switch to provide notification_drivers = x, y ,z
14:09:04 <ajo> it's the core plugin responsible to provide a
14:09:13 <ajo> "get_qos_driver" method
14:09:55 <njohnston_> In your opinion is this a pattern that can be generalized to other similar use cases?
14:10:06 <ajo> for ml2, I made it go through the mechanism driver to return a manager with all the possible qos drivers via a single callable (basically the current notification driver manager)
14:10:22 <ajo> njohnston_, use cases which are coupled to the specific core plugin: yes
14:10:40 <njohnston_> good, good
14:10:51 <ajo> njohnston_, I'd guess that for fwaas, you're coupled to the l3 service
14:11:19 <njohnston_> L2 and L3, now... we're using agent extensions for both kinds of agents
14:11:34 <ajo> yes, the agent extensions look good
14:12:01 <ajo> so, that's more or less the history
14:12:19 <ajo> if you want to look on how trunk ports are being developed,
14:12:36 <ajo> https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/vlan-aware-vms
14:12:56 <ajo> may be specifically https://review.openstack.org/#/c/347662/
14:12:58 <njohnston_> So it sounds like everything is pending working out the kinks for this revamp of notifications.
14:13:42 <ajo> It's not clear that we can find a common way of doing all those cases
14:13:51 <ajo> but, having a common way would be the ideal
14:13:53 <ajo> IMO
14:14:08 <njohnston_> Something to work on in Ocata :-)
14:14:23 <ajo> so ihrachys , if you can sync tomorrow or friday, I'd be happy to
14:14:37 <njohnston_> OK, moving on.
14:14:44 <njohnston_> #link https://bugs.launchpad.net/neutron/+bug/1560963
14:14:44 <openstack> Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:14:44 <njohnston_> ralonsoh has been working on this change recently
14:14:44 <njohnston_> #link https://review.openstack.org/#/c/344145/
14:15:06 <ralonsoh> I need reviews
14:15:37 <njohnston_> I think that will be the theme for today
14:15:50 <ajo> ralonsoh, I'll go back to it, sorry,
14:15:59 <ajo> ralonsoh, explained me the technical details last week
14:16:10 <ralonsoh> no problem.
14:16:17 <ralonsoh> which technical details?
14:16:25 <ralonsoh> this commit is only the front end
14:16:36 <ralonsoh> front end: https://review.openstack.org/#/c/344145/
14:16:40 <ajo> and while there were some limitations on the model, he found a better way to do it (than I had in mind)
14:16:45 <ajo> I was talking of the RFE in general :)
14:16:45 <ralonsoh> I think this won't have any problem
14:16:53 <ralonsoh> yes
14:16:58 <ajo> the OVS implementation in particular
14:16:58 <ralonsoh> OVS implementation
14:17:02 <ajo> yup
14:17:02 <ralonsoh> one sec
14:17:04 <ajo> also
14:17:16 <ajo> ralonsoh, has been working on the client side
14:17:20 <ajo> openstack client,
14:17:25 <ralonsoh> OVS implementation: https://review.openstack.org/#/c/318531/
14:17:34 <ajo> to avoid the server side being locked by this.
14:18:08 <ralonsoh> OSclient: I'm writing all bugs in https://etherpad.openstack.org/p/osc-neutron-support
14:18:24 <ralonsoh> You can follow the work on the OSC in this etherpad
14:18:28 <ajo> we could even release backend (LB or SRIOV) & frontend  & openstack client if we get caught by time, and leave OVS for Ocata
14:18:44 <ralonsoh> That could be great
14:18:53 <njohnston_> +1
14:18:57 <ralonsoh> Thanks!
14:19:25 <njohnston_> ok, next up
14:19:31 <njohnston_> #link https://bugs.launchpad.net/neutron/+bug/1560961
14:19:31 <openstack> Launchpad bug 1560961 in neutron "[RFE] Allow instance-ingress bandwidth limiting" [Wishlist,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:19:31 <njohnston_> slaweq has been hard at work here
14:19:31 <njohnston_> #link https://review.openstack.org/303626
14:19:43 <slaweq> I wanted to talk about this one
14:19:43 <ajo> probably needing reviews too, I suspect ':)
14:19:56 <slaweq> I made it for now as depend on this rule validation
14:20:13 <slaweq> but maybe we can go with it without improvement validation
14:20:20 <ajo> so we have an interesting chain of events
14:20:30 <slaweq> ajo: yes
14:20:46 <ajo> slaweq, could it be made not dependent on rule validation to avoid locking ?
14:20:46 <slaweq> but I think that validation can be not done in Newton :/
14:21:05 <ajo> we can just write a log warning for now in the backends not supporting that
14:21:07 <slaweq> yes, it can be not depend on rule validation
14:21:12 <slaweq> ajo: exactly
14:21:27 <slaweq> I was thinking that because for now we also have no validation in fact
14:21:29 <ajo> as long as the long term plan is clear, and we properly document that, I'm good with that
14:21:30 <ajo> ihrachys,  ^
14:21:34 <ajo> is that ok with you too?
14:21:36 <slaweq> and some rules are not supported by some agents
14:21:51 <ihrachys> ajo: yes, I don't think they MUST be bound.
14:21:52 <slaweq> so it will not change anything IMHO
14:22:12 <ihrachys> slaweq++
14:22:15 <ajo> slaweq++
14:22:18 <slaweq> thx
14:22:25 <ajo> thank *you* sir
14:22:25 <slaweq> so this one should be ready for review
14:22:27 <slaweq> :)
14:22:32 <njohnston_> ++reviews!
14:22:37 <ihrachys> slaweq: links? are those rodolfo's patches?
14:22:51 <ajo> no, this is ingress bw limit, wait
14:23:04 <slaweq> ihrachys: my patch for review is: https://review.openstack.org/#/c/303626/
14:23:07 <ajo> #link https://review.openstack.org/#/c/303626/
14:23:29 <ihrachys> ajo: how do we stand on rodolfo's?
14:23:33 <slaweq> and I started working on ovs agent support currently: https://review.openstack.org/#/c/341186/ but it's not finished yet
14:23:49 <ihrachys> I feel that we repeat the pattern from Mitaka when we slipped dscp
14:23:54 <ajo> ihrachys, sorry, I must have pinged you, that was the previous rfe
14:23:55 <slaweq> locally I have also support for linuxbridge so I will try to finish it and push both to review asap
14:24:11 <ajo> ihrachys, he's working on the openstack client (new requirement) to speed up things
14:24:22 <ajo> ihrachys, he has a good foundation for the frontend
14:24:33 * njohnston_ has openstack client as the next topic
14:24:40 <ajo> and ihrachys , I'm ok if OVS support slips off this release, because that one is a bit more complicated
14:24:46 <ajo> if we get it, great
14:24:58 <ajo> if we don't , then, next release is ok for me
14:25:01 <ihrachys> ajo: we'll have linuxbridge?
14:25:19 <ralonsoh> for min_bw_egress yes
14:25:23 <ralonsoh> I'm working on it
14:25:50 <ajo> ihrachys,  he has SR-IOV ready
14:25:52 <ihrachys> we need at least one backend
14:26:05 <ajo> and, being SR-IOV the origin of this RFE, I'd be happy
14:26:16 <ihrachys> ok
14:26:35 <ajo> #link https://review.openstack.org/#/c/347302/
14:26:47 <ajo> this came from operators using SR-IOV wanting min bw support :)
14:27:47 <njohnston_> OK, moving on
14:27:53 <ajo> so, ralonsoh to focus things, can we concentrate efforts on frontend + sr-iov + cli ?
14:27:56 <njohnston_> #topic openstack client
14:27:56 <njohnston_> #link https://blueprints.launchpad.net/python-openstackclient/+spec/neutron-client-qos
14:27:56 <njohnston_> ralonsoh has been breaking this up into bugs and implementing it
14:28:04 <njohnston_> Here are the changes he has put in so far:
14:28:05 <njohnston_> #link https://review.openstack.org/350655
14:28:05 <njohnston_> #link https://review.openstack.org/351187
14:28:06 <njohnston_> #link https://review.openstack.org/352789
14:28:08 <njohnston_> #link https://review.openstack.org/351565
14:28:10 <njohnston_> #link https://review.openstack.org/352477
14:28:15 <ralonsoh> ajo: i'm on it now
14:28:19 <njohnston_> lots of really good work here
14:28:22 <ajo> holy *wow* :)
14:29:09 <slaweq> ralonsoh: what about Bandwidth limit rule commands?
14:29:20 <slaweq> there is no bug reported for this one?
14:29:24 <ralonsoh> give me one week
14:29:31 <ralonsoh> i'll finish all qos commands
14:29:39 <ralonsoh> on sdk and OSclient
14:29:53 <njohnston_> Way to go ralonsoh, you're a machine
14:30:27 <ajo> :)
14:31:00 <njohnston_> #topic Bugs
14:31:00 <njohnston_> #link http://bit.ly/1WhXlzm
14:31:12 <njohnston_> #link https://bugs.launchpad.net/neutron/+bug/1600708
14:31:12 <openstack> Launchpad bug 1600708 in neutron "Update ‘--max-kbps’ and ‘--max-burst-kbps’ parameter to 2147483648 or greater than 2147483648 using qos-bandwidth-limit-rule-update command，Neutron server thrown an exception" [Low,In progress] - Assigned to QunyingRan (ran-qunying)
14:31:12 <njohnston_> This has a fix, it looks like it needs reviews.
14:31:12 <njohnston_> #link https://review.openstack.org/#/c/350491/
14:32:01 <njohnston_> so please take a look at it
14:32:24 <ajo> +2'd, makes sense and it's simple
14:32:34 <njohnston_> excellent!
14:32:39 <njohnston_> #link https://bugs.launchpad.net/neutron/+bug/1608921
14:32:39 <openstack> Launchpad bug 1608921 in neutron "The signature of the QoSPluginBase methods is wrong" [Wishlist,In progress] - Assigned to Miguel Angel Ajo (mangelajo)
14:32:39 <njohnston_> This also looks good, it just needs +2 reviews.
14:32:39 <njohnston_> #link https://review.openstack.org/#/c/349965/
14:32:59 <ajo> Yes, that one is very low prio, just cosmetic details
14:33:23 <ajo> some parameters on the api definition were in wrong order
14:33:31 <ajo> that's never checked by abs.abstract method
14:33:47 <ajo> and In some places we were using _obj to refer classes,
14:33:59 <ajo> can be considered a clean up,
14:34:17 <ajo> I'll discuss that in my sync with ihrachys and get reviewer attention,
14:34:22 <ajo> but it's unimportant stuff actually
14:34:26 <njohnston_> ok
14:34:42 <njohnston_> #link https://bugs.launchpad.net/neutron/+bug/1587291
14:34:42 <openstack> Launchpad bug 1587291 in neutron "Specifying '-F' or '--filed' parameter in the qos related commands, returns abnormal result" [Undecided,In progress] - Assigned to dongwenshuai (dong-wenshuai)
14:34:42 <njohnston_> This one has been out there a while, but I just added the 'qos' tag.  Looks like it needs reviews as well.
14:34:42 <njohnston_> #link https://review.openstack.org/329852
14:35:15 <njohnston_> I just noticed it before the meeting, I haven't had time to really look at it.
14:35:54 <ajo> what's -F ?
14:38:10 <njohnston_> --fields
14:39:39 <njohnston_> #topic Open Discussion
14:39:49 <njohnston_> Anyone have anything else we didn't cover?
14:40:28 <ajo> I certainly need more sleep :)
14:40:40 <davidsha> +1
14:41:18 <njohnston_> All right, I think that's it then.  Thanks, everyone!
14:41:23 <davidsha> Thanks
14:41:27 <njohnston_> Next time we meet, N-3 will be close at hand
14:41:27 <ajo> thanks a lot , and thanks for all the hard work
14:41:38 <njohnston_> #endmeeting