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