14:00:02 <njohnston> #startmeeting neutron_qos
14:00:03 <openstack> Meeting started Wed Aug 24 14:00:02 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:04 <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:16 <njohnston> #chair ajo
14:00:24 <openstack> Current chairs: ajo njohnston
14:00:27 <njohnston> #link https://etherpad.openstack.org/p/neutron_qos_meeting_chair for the meeting agenda
14:00:31 <njohnston> good morning all
14:00:35 <ralonsoh> hi
14:00:44 <davidsha> Hey
14:01:29 <njohnston> ok lets get started
14:01:35 <njohnston> #topic openstack client
14:01:36 <slaweq_> hi
14:01:46 <njohnston> ralonsoh has been rocking the implementation of this
14:01:56 <ralonsoh> hehe
14:01:59 <njohnston> But since OSC has been released, does this mean we missed the boat for inclusion in Newton?
14:02:05 <ralonsoh> still waiting for the sdk patches
14:02:17 <ralonsoh> maybe...
14:02:27 <njohnston> for everyone's reference, here is the list of patches - ralonsoh let me know if I missed one
14:02:30 <njohnston> #link https://review.openstack.org/350655
14:02:30 <njohnston> #link https://review.openstack.org/351187
14:02:30 <njohnston> #link https://review.openstack.org/352789
14:02:32 <njohnston> #link https://review.openstack.org/351565
14:02:34 <njohnston> #link https://review.openstack.org/352477
14:03:18 <ralonsoh> njohnston: that means no new qos features this release?
14:03:28 <ralonsoh> in neutron?
14:03:40 <davidsha> DSCP
14:03:55 <ralonsoh> yes, that was approved last cycle
14:03:56 <njohnston> well, DSCP will still be supported by the old neutron client
14:04:22 <ralonsoh> one quick question: if if have min-bw in old neutron client....
14:04:31 <ralonsoh> can we have this accepted in neutron?
14:04:39 <njohnston> but as far as the openstack client, I'm not 100% sure - there may be a bugfix release, I heard about a 3.0.1 being released - but I think there is a good chance it will miss this iteration
14:04:40 <ralonsoh> at least front-end and sr-iov
14:04:58 <davidsha> You would need this in Neutron first then in python client I believe.
14:05:24 <slaweq_> AFAIK policy for neutronclient is that first it should be on server side
14:05:38 <njohnston> correct
14:05:44 <ralonsoh> ok, thanks!
14:05:46 <slaweq_> but for osc it is in opposite way, so You can push patches to osc
14:05:53 <slaweq_> and then finish neutron side
14:06:07 <ralonsoh> slaweq_: right!
14:06:19 <njohnston> ralonsoh: ping rtheis, he can give you the best advice for getting things in to this release
14:06:42 <ralonsoh> njohnston: I'm talking with him
14:06:47 <njohnston> very good
14:06:49 <ralonsoh> both for sdk and OSclient
14:07:11 <njohnston> ralonsoh: anything else on this topic?
14:07:16 <ralonsoh> no thanks
14:07:22 <njohnston> #topic RFEs
14:07:34 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1586056
14:07:34 <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:07:34 <njohnston> #link https://review.openstack.org/#/c/319694/
14:07:34 <njohnston> Validation change - haven't seen a lot of work on this lately
14:07:43 <slaweq_> nothing changed here
14:07:56 <slaweq_> it will not be ready for Newton for sure :/
14:08:12 <njohnston> and the change to the QoS notification structure that got spun out of this also looks like it has not progressed
14:08:13 <slaweq_> ajo is working on some refactor/rename of notification drivers
14:08:20 <njohnston> #link https://review.openstack.org/#/c/351858/
14:08:46 <njohnston> next up
14:08:48 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1560963
14:08:48 <openstack> Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
14:09:10 <njohnston> ralonsoh has also been active on this recently
14:09:18 <njohnston> #link https://review.openstack.org/#/c/344145/ - front end
14:09:18 <njohnston> #link https://review.openstack.org/#/c/318531/ - ovs implementation (WIP)
14:09:18 <njohnston> #link https://review.openstack.org/#/c/357865/ - LBridge implementation (WIP)
14:09:40 <ralonsoh> and sr-iov
14:09:42 <ralonsoh> one sec
14:09:44 <njohnston> how is it going, ralonsoh?  Is it to the point where you need serious review attention?
14:09:53 <ralonsoh> https://review.openstack.org/#/c/347302/
14:09:58 <ralonsoh> Waiting for reviews...
14:10:03 <ralonsoh> first the front-end
14:10:04 * njohnston adds that to the agenda
14:10:08 <slaweq_> ralonsoh: sorry, I didn't have time to look on it
14:10:11 <ralonsoh> and then the sr-iov patch
14:10:15 <ralonsoh> I know
14:10:15 <slaweq_> I will try today
14:10:23 <ralonsoh> Too many reviews!
14:11:12 <ralonsoh> last thing: I'll be back on 6 september, but i'll look at gerrit
14:11:14 <njohnston> Anything to add on that?
14:11:21 <ralonsoh> no thanks
14:11:30 <njohnston> ralonsoh: Enjoy your PTO!
14:11:34 <ralonsoh> thanks!
14:11:39 <njohnston> #topic Bugs
14:11:49 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1614728
14:11:49 <openstack> Launchpad bug 1614728 in neutron "qos: rule list in policy is too difficult to use" [Undecided,New]
14:11:49 <njohnston> new bug - kind of seems like it should be classified 'opinion' IMO
14:12:35 <yamahata> Hi.
14:12:54 <slaweq_> I think it will be not easy to fix as it's changing what API returns
14:12:55 <yamahata> Is it difficult to change the format at this phase?
14:13:17 <njohnston> I believe we may need to deprecate the old format in order to introduce a new format
14:13:41 <njohnston> I can't speak to why this format was chosen per se, I wasn't involved at that point
14:14:09 <yamahata> did we have a process/discussion to change the format?
14:14:41 <yamahata> Should we keep old format?
14:15:00 <njohnston> yamahata: I recommend you put up a patch in gerrit, and we can discuss the merits of it there.
14:15:07 <yamahata> Okay thanks.
14:15:14 <njohnston> That will also let us involve people that are still on end-of-August PTO
14:15:20 <yamahata> Actually I have another bug which I didn't file yet.
14:15:27 <njohnston> Oh, what's that?
14:15:42 <yamahata> according to neutorn/extension/qos.py
14:15:47 <yamahata> rule has tenant_id.
14:16:04 <yamahata> On the other hand, according to dbmodel and ovo object, rule doesn't have tenant_id.
14:16:17 <yamahata> The actual output doesn't.
14:16:44 <yamahata> I'm not sure which is the intent/design.
14:17:13 <njohnston> Hmm, that sounds like it might be a good bug, plus perhaps an email to openstack-dev to kickstart a discussion
14:17:17 <ralonsoh> yes, you are right. it's a bug
14:17:58 <yamahata> Okay, let me file a bug and kick a discussion in the mailing list.
14:18:07 <njohnston> thanks, yamahata!
14:18:29 <njohnston> next up
14:18:31 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1608921
14:18:31 <openstack> Launchpad bug 1608921 in neutron "The signature of the QoSPluginBase methods is wrong" [Wishlist,In progress] - Assigned to Nate Johnston (nate-johnston)
14:18:31 <njohnston> #link https://review.openstack.org/#/c/349965/ just waiting for the +2 from Jenkins after a rebase
14:19:04 <njohnston> then
14:19:06 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1587291
14:19:06 <openstack> Launchpad bug 1587291 in neutron "Specifying '-F' or '--filed' parameter in the qos related commands, returns abnormal result" [Low,In progress] - Assigned to dongwenshuai (dong-wenshuai)
14:19:10 <njohnston> #link https://review.openstack.org/329852 needs core reviewers
14:19:19 <njohnston> but otherwise looks to be in good order
14:19:39 <njohnston> and finally
14:19:41 <njohnston> #link https://bugs.launchpad.net/neutron/+bug/1515564
14:19:42 <openstack> Launchpad bug 1515564 in neutron "Internal server error when running qos-bandwidth-limit-rule-update as a tenant" [Low,In progress] - Assigned to Slawek Kaplonski (slaweq)
14:19:46 <njohnston> #link https://review.openstack.org/#/c/358275/
14:19:59 <njohnston> slaweq_ is all over this, how is it going?
14:20:03 <slaweq_> Maybe it's related to bug which yamahata found
14:20:04 <davidsha> I have one to add when this is covered
14:20:22 <slaweq_> I pushed patch https://review.openstack.org/#/c/358275/ and waiting for reviews
14:20:45 <slaweq_> but maybe it is related to this "tenant_id" in qos extension definition
14:20:52 <slaweq_> I will check it today
14:21:17 <njohnston> OK, davidsha what do you have for us?
14:21:23 <davidsha> https://bugs.launchpad.net/neutron/+bug/1603443
14:21:23 <openstack> Launchpad bug 1603443 in neutron "[QoS][DSCP] 'delete_dscp_marking' function raises exception, 'vif_port' not present" [Undecided,Confirmed] - Assigned to David Shaughnessy (david-shaughnessy)
14:21:53 <njohnston> I just added the qos tag to that
14:21:54 <davidsha> ralonsoh found a bug a few weeks back, an exception is thrown when you delete a port with a dscp marking rule attached
14:22:28 <davidsha> I have a PS up for it here and expanded the tests to include it: https://review.openstack.org/#/c/345915/
14:22:44 <njohnston> excellent
14:23:21 <njohnston> I'll take a look at that later, seems like something we should try to get a fix in for this release
14:23:22 <davidsha> basically the port info is deleted by the time it gets to delete the dscp rule and we can't leave it be as the flow will stay in the flow table.
14:24:15 <davidsha> so it retains the info and uses the port id + qos rule type to retrieve the info.
14:24:24 <njohnston> looks like the linuxbridge test failed with a transient error ('Build of instance 3bef83e3-b53d-48fc-b8fb-d696b181ffbb aborted: Failed to allocate the network(s), not rescheduling.') so you may want to recheck
14:24:38 <davidsha> will do
14:25:10 <njohnston> anything else on that davidsha?
14:25:50 <davidsha> nothing else, reviews would be appreciated!
14:25:58 <njohnston> super
14:25:58 <njohnston> #topic Other Changes
14:26:04 <njohnston> #link https://review.openstack.org/356593 Qos Network Policy Binding OVO
14:27:00 <njohnston> lots of OVO work, we should all be aware of it.  Not sure if there are other QoS ones, I just happened to see that one fly by recently
14:27:35 <njohnston> and there was an update to the QoS devref also
14:27:40 <njohnston> #link https://review.openstack.org/355909
14:27:44 <njohnston> but that one already merged
14:28:25 <njohnston> #topic Open Discussion
14:28:36 <njohnston> Anyone have anything for us to talk about?
14:28:41 <slaweq_> I want to ask You to review https://review.openstack.org/#/c/303626/
14:29:13 <slaweq_> and https://review.openstack.org/#/c/341186/ - this is waiting for patch to ovs_lib but I would be grateful for review it also :)
14:29:41 <ralonsoh> good work!
14:29:48 <njohnston> 303626 has the same transient linuxbridge failure
14:29:57 <davidsha> will do!
14:30:04 <slaweq_> yes, I didn't recheck it yet
14:31:04 <njohnston> thanks, slaweq_, I'll check those out
14:31:27 <slaweq_> thx
14:31:29 <njohnston> If there's nothing else, I'll give you half an hour back
14:32:13 <njohnston> Thanks all.
14:32:15 <ralonsoh> bye!
14:32:16 <njohnston> #endmeeting