15:00:57 <ralonsoh> #startmeeting neutron_qos
15:00:58 <openstack> Meeting started Tue Apr 25 15:00:57 2017 UTC and is due to finish in 60 minutes.  The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:01 <openstack> The meeting name has been set to 'neutron_qos'
15:01:03 <ralonsoh> hello
15:01:07 <davidsha> Hey
15:01:22 <slaweq> hello
15:01:55 <mlavalle> o/
15:01:57 <ralonsoh> ok, let's start
15:02:00 <ralonsoh> #topic RFEs
15:02:09 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=qos+rfe+&field.tags_combinator=ALL RFEs
15:02:19 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1639220
15:02:20 <openstack> Launchpad bug 1639220 in neutron "[RFE] Introduce Network QoS policy "is_default" behaviour" [Low,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
15:02:37 <ralonsoh> this one is almost almost finished (like two weeks ago...)
15:02:44 <slaweq> :)
15:02:48 <ralonsoh> I solved the last problems and now I'm testing
15:02:56 <ralonsoh> but no more problems
15:03:22 <ralonsoh> I'll ask you for reviews maybe tomorrow
15:03:26 <ralonsoh> next one
15:03:30 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1505627
15:03:32 <openstack> Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,New] - Assigned to Reedip (reedip-banerjee)
15:03:47 <ralonsoh> reedip, is this one on hold?
15:04:26 <ralonsoh> there is no progress so far, any problem with the spec?
15:04:58 <ralonsoh> ok, I'll try to ping reedip a bit later
15:05:01 <ralonsoh> next one
15:05:03 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1596611
15:05:04 <openstack> Launchpad bug 1596611 in neutron "[RFE] Create L3 IPs with qos (rate limit)" [Wishlist,In progress] - Assigned to LIU Yulong (dragon889)
15:05:21 <ralonsoh> It's also my fault: I didn't take care of this spec
15:05:42 <ralonsoh> I think it could be accepted this cycle
15:05:50 <ralonsoh> but it's a bit late
15:06:07 <ralonsoh> please, make the effort and review this one
15:06:16 <davidsha> ack
15:06:26 <slaweq> ok, I will look on it also
15:06:29 <ralonsoh> next one
15:06:31 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1634798
15:06:32 <openstack> Launchpad bug 1634798 in neutron "[RFE] Qos DSCP to vlan priority mapping" [Wishlist,Incomplete]
15:06:39 <ralonsoh> I'll remove this one from the next list
15:06:48 <ralonsoh> it's incomplete and no feedback
15:07:05 <ralonsoh> next one
15:07:06 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1686035
15:07:07 <openstack> Launchpad bug 1686035 in neutron "More detailed reporting of available QoS rules" [Undecided,New] - Assigned to Slawek Kaplonski (slaweq)
15:07:09 <ralonsoh> this one is new
15:07:13 <ralonsoh> slaweq?
15:07:19 <slaweq> yep, I created it today :)
15:07:32 <ralonsoh> about bullet 1
15:07:34 <slaweq> so basically after "improved validation" for rules was merged
15:07:55 <slaweq> qos_available_rules call to neutron returns IMHO wrong data (not complete)
15:08:18 <slaweq> currently it returns subset of rule types supported by all used drivers
15:08:52 <ralonsoh> yes, that was decided, if the qos policy is not assigned to any port/net
15:08:58 <slaweq> so if we have e.g. sriov and ovs drivers than minimum_bw_limit_rule will not be shown as available
15:09:04 <slaweq> because ovs is not supporting it
15:09:21 <slaweq> and IMHO this is wrong because user can apply it to ports bound with sriov driver
15:09:54 <slaweq> so IMHO it should be changed that all rules supported by at least one driver should be returned in this API call
15:10:10 <ralonsoh> just the opposite
15:10:18 <slaweq> yep
15:10:36 <slaweq> that's my idea but maybe someone has got different idea :)
15:10:38 <ralonsoh> and if this rule is attached to a port/net, then check the qos policy and rules
15:10:43 <ralonsoh> is that correct?
15:11:14 <slaweq> when operator will want to attach rule (policy) to port/net validation mechanism will check if such rule is supported by this driver
15:11:22 <slaweq> and will return error if it's not supported
15:11:25 <ralonsoh> oooook
15:11:32 <ralonsoh> that's much better
15:11:32 <slaweq> so it will be not applied
15:11:58 <ralonsoh> you are right: you can't avoid a user to create a min rule only because you have LB and SRIOV
15:12:04 <ralonsoh> for example
15:12:22 <ralonsoh> because you want to assign this qos policy/rule to LB
15:12:29 <slaweq> in fact it's not avaided but now it's not reported to user that he can use it
15:12:47 <ralonsoh> ok
15:12:54 <slaweq> now even if rule is not returned as available You still can create it
15:12:58 <slaweq> :)
15:13:07 <ralonsoh> ok, perfect
15:13:10 <ralonsoh> and the second part
15:13:15 <ralonsoh> give more information
15:13:28 <ralonsoh> rules and parameters
15:13:43 <slaweq> the second part is something what yamamoto pointed in review for ingress bw limit patch
15:13:57 <ralonsoh> yes, I saw this
15:14:05 <slaweq> he asked how user can discover via API that something like "ingress" direction is available in his cloud
15:14:33 <ralonsoh> I think we need to expand rule_types
15:14:37 <slaweq> so IMHO we can provide new API call to show users details about what rule types are available for what drivers and with which parameters
15:15:04 <ralonsoh> yes: rule types, driver and parameters, the whole pack!
15:15:07 <slaweq> I don't want to change response for existing API call because that would be very hard to do
15:15:40 <slaweq> ralonsoh: exactly :)
15:15:42 <ralonsoh> you mean to create a new API call, not to expand rule_types?
15:16:15 <slaweq> yep, because probably it will be very hard to get merged such change of existing API call (compatibility, no microversioning, etc.)
15:16:56 <ralonsoh> ok, we can discuss this later
15:16:59 <ralonsoh> the second part
15:17:04 <slaweq> but if You think differently, we can try to expand existing call
15:17:43 <ralonsoh> ok, if we need to talk a bit more, we can use neutron channel for this rfe
15:17:51 <slaweq> yes
15:17:53 <ralonsoh> let's go to bugs
15:17:57 <ralonsoh> #topic Bugs
15:18:05 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1683365
15:18:06 <openstack> Launchpad bug 1683365 in neutron "test_rule_update_forbidden_for_regular_tenants_own_policy fails with NotFound" [Medium,Confirmed]
15:18:32 <ralonsoh> I'm testing this one and reviewing the logs
15:18:39 <ralonsoh> I can't find the problem...
15:18:47 <ralonsoh> I need to talk to Ihar
15:19:11 <slaweq> if You want some help, I can check it also
15:19:18 <ralonsoh> I'll ping you
15:19:20 <slaweq> ok
15:19:31 <ralonsoh> because I'm having some troubles with that
15:19:36 <ralonsoh> I need a bit of time
15:19:46 <ralonsoh> next one
15:19:47 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1676877
15:19:49 <openstack> Launchpad bug 1676877 in neutron "Increase "TestQosPlugin.test_update_policy_rule" coverage" [Medium,In progress] - Assigned to Reedip (reedip-banerjee)
15:20:15 <ralonsoh> I'll talk to reedip later, he's busy now
15:20:25 <ralonsoh> next one
15:20:27 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1667138
15:20:28 <openstack> Launchpad bug 1667138 in neutron "Minumum bandwidth can be higher than maximum bandwidth limit in same QoS policy" [Medium,In progress] - Assigned to Reedip (reedip-banerjee)
15:20:33 <ralonsoh> the same
15:20:39 <ralonsoh> next one
15:20:43 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1657381
15:20:43 <openstack> Launchpad bug 1657381 in neutron "QoS drivers need to implement a precommit for the actions" [Medium,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
15:20:54 <mlavalle> ralonsoh: he is benn making progress on that one
15:20:59 <mlavalle> been^^^
15:21:16 <mlavalle> I've looked at the patchset several times
15:21:19 <ralonsoh> which one?
15:21:31 <ralonsoh> 1667138
15:21:36 <ralonsoh> yes, I've seen it
15:21:37 <mlavalle> correct
15:21:42 <ralonsoh> 1667138 is almost finish
15:22:01 <mlavalle> I think so
15:22:03 <ralonsoh> just the last sprint, but now he is a bit busy
15:22:20 <mlavalle> the latest comments have been on the unit tests
15:22:59 <ralonsoh> yes, small problems in the qos_plugin
15:23:10 <ralonsoh> but I don't think there is any problem in this patch
15:23:31 <ralonsoh> 1657381: this is ajo's patch
15:23:40 <mlavalle> agree
15:23:52 <ralonsoh> I took care of it, I submitted the last commit 30 mins ago
15:24:25 <ralonsoh> If you have time... reviews will be appreciated
15:24:43 <mlavalle> ralonsoh: yeah I saw that you pushed a review yesterday
15:24:44 <slaweq> ok, I will check
15:24:49 <mlavalle> hadn't seen the latest one
15:24:59 <mlavalle> I am keeping an eye on it
15:25:03 <ralonsoh> thanks
15:25:09 <mlavalle> will review again
15:25:18 <ralonsoh> last ones, related to #link https://bugs.launchpad.net/neutron/+bug/1560961
15:25:19 <openstack> Launchpad bug 1560961 in neutron "[RFE] Allow instance-ingress bandwidth limiting" [Wishlist,In progress] - Assigned to Slawek Kaplonski (slaweq)
15:25:31 <ralonsoh> API: #link https://review.openstack.org/#/c/449831/
15:25:44 <ralonsoh> OVS: #link https://review.openstack.org/#/c/457816/
15:25:44 <slaweq> this one is almost done (I hope)
15:25:52 <slaweq> and OVS is also ready to review I thing
15:25:56 <ralonsoh> yes, api is almost done (fast work!!!)
15:26:06 <ralonsoh> ovs: I have this in my TODO list
15:26:07 <slaweq> I will now start also working on Linuxbridge
15:26:13 <ralonsoh> perfect!
15:26:23 <ralonsoh> add us as reviewers
15:26:29 <ralonsoh> I need to check OVS today
15:26:40 <slaweq> ok, I will add all of You
15:27:29 <ralonsoh> next topic
15:27:34 <ralonsoh> #topic Other Changes
15:27:46 <ralonsoh> I moved the spec #link https://bugs.launchpad.net/neutron/+bug/1578989
15:27:47 <openstack> Launchpad bug 1578989 in neutron "[RFE] Strict minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
15:27:50 <ralonsoh> to this section
15:28:10 <ralonsoh> mlavalle, how is the API to Nova going?
15:28:24 <mlavalle> ralonsoh: I've made some slow progress
15:28:37 <mlavalle> I will be teaching a class during summit
15:28:43 <mlavalle> so preparing my presentation
15:28:49 <ralonsoh> I know
15:28:51 <mlavalle> will get faster after summit
15:28:54 <ralonsoh> good luck with this
15:29:06 <ralonsoh> ok, we will talk after the summit
15:29:21 <ralonsoh> I think this feature will be delayed to the next cycle
15:29:30 <ralonsoh> but it's ok
15:29:46 <mlavalle> yeah but even in that scenario I want to make progress as fast as I can
15:29:57 <ralonsoh> for sure, and I'll help with that
15:30:05 <mlavalle> that way we provide feedback to the nova team
15:30:21 <mlavalle> which is really our critical path
15:30:26 <ralonsoh> yes, I know
15:30:41 <ralonsoh> is very difficult to make Nova changes....
15:31:07 <ralonsoh> perfect, next section
15:31:08 <ralonsoh> #topic Open Discussion
15:31:17 <ralonsoh> I have nothing in the agenda
15:31:25 <ralonsoh> for this section
15:31:50 <ralonsoh> Enjoy your preps for the summit!
15:32:31 <mlavalle> Thanks
15:32:35 <hichihara> ralonsoh: I have a question
15:32:43 <ralonsoh> please, hichihara
15:32:55 <hichihara> ralonsoh: Any updates about LB and OVS of minimum bandwitdh?
15:33:40 <ralonsoh> no: I abandoned the LB implementation, because it requires a unique QoS class for all the traffic in the ibt-br
15:33:45 <ralonsoh> int-br
15:33:59 <ralonsoh> that means a performance hit
15:34:25 <ralonsoh> also if you have several VLANs in LB, you'll have several LBs
15:34:34 <ralonsoh> the architecture is quite complex
15:34:43 <ralonsoh> and I don't see a method to implement it
15:35:22 <ralonsoh> and for OVS, after 9 months trying to deliver it, I abandoned the patch
15:35:24 <hichihara> ralonsoh: You mean that we can get SR-IOV only about minimum bandwidth?
15:35:36 <ralonsoh> now that's correct
15:35:50 <slaweq> ralonsoh: to be clear, complex implementation is for OVS or LB?
15:36:02 <ralonsoh> do you have a possible architecture for LB or OVS for min-bw?
15:36:08 <slaweq> because in LB there is no int-br AFAIK
15:36:11 <ralonsoh> slaweq, yes
15:36:22 <hichihara> ralonsoh: It's possible for me
15:36:28 <ralonsoh> slaweq, yes, there is no bridge
15:36:37 <ralonsoh> there is a bridge per VLAN
15:36:47 <ralonsoh> hichihara, which backend?
15:37:03 <hichihara> ralonsoh: both
15:37:20 <ralonsoh> hichihara, BTW, I submitted several patches during the last year with no feedback
15:37:45 <ralonsoh> for LB, how are you planning to do this?
15:38:27 <hichihara> ralonsoh: I thought you want to propose document to clear the coomplex implementations...
15:39:28 <ralonsoh> hichihara, yes. But just in a couple of lines: how are you going to implement min-bw in LB?
15:39:47 <hichihara> ralonsoh: https://review.openstack.org/#/c/415144/ This is for OVS but I guess that we can use the tc_lib implementation for linuxbridge
15:41:00 <ralonsoh> https://review.openstack.org/#/c/415144/: this one is only for tunnel traffic (what you need, I now), and doesn't work with user space OVS
15:41:13 <hichihara> Actually the implementation executes TC to linux interface.
15:41:27 <ralonsoh> of course, is a valid implementation, but with limitations
15:41:55 <hichihara> ralonsoh: We must implement into user space OVS?
15:42:03 <ralonsoh> I now, you are using TC in the interface
15:42:14 <ralonsoh> hichihara, what do you mean?
15:42:48 <hichihara> ralonsoh: yes because OVS doesn't support minimum bandwidth QoS
15:43:01 <ralonsoh> it does
15:43:37 <ralonsoh> OVS uses the same scheduler as TC
15:43:52 <ralonsoh> in fact, kernel OVS calls TC to setup it
15:44:18 <ralonsoh> ok, last quick question
15:44:22 <hichihara> ralonsoh: I didn't know... Could you tell me the point?
15:44:43 <hichihara> ralonsoh: I thought OVS support limit rule only
15:45:09 <davidsha> hichihara: htb has a min_bw feature as well I believe
15:45:35 <ralonsoh> if you implement the QoS rules using only the OVS interface, you won't have problems with other OVS implementations
15:45:52 <ralonsoh> e.g., user space OVS
15:46:04 <ralonsoh> that's other discussion
15:46:09 <ralonsoh> LB implementation?
15:46:11 <mlavalle> ralonsoh: I have a couple of things I want to share with the team, but I am multi-tasking. When you are done with this discussion, please ping me
15:46:22 <ralonsoh> mlavalle, ok
15:46:56 <ralonsoh> hichihara, LB implementation? how are you planning to implement it?
15:47:44 <ralonsoh> davidsha, you are right, because OVS uses TC scheduler
15:48:09 <hichihara> ralonsoh: I just guessed that we may use above my patch. I'm not sure.
15:48:26 <hichihara> ^^^ may be able to use
15:48:56 <hichihara> Actually I considered OVS only
15:49:21 <ralonsoh> I spent 6 months in a LB implementation (buggy, not working as you know)
15:49:41 <ralonsoh> First it's better if you share in a small document how are you planning to do this
15:49:54 <ralonsoh> this is the best way to avoid working for nothing (like me)
15:50:05 <hichihara> ralonsoh: I think so.
15:50:14 <ralonsoh> perfect!
15:50:29 <ralonsoh> QoS group is on fire!!
15:50:30 <hichihara> ralonsoh: I'll consider it again. Thanks
15:50:42 <ralonsoh> mlavalle, how are you sir?
15:50:47 <slaweq> ralonsoh: :D
15:51:09 <mlavalle> ralonsoh, slaweq: this blueprint https://blueprints.launchpad.net/neutron/+spec/instance-ingress-bw-limit
15:51:34 <mlavalle> was discussed briefly during the last Neutron drivers meeting, this past Thursday
15:51:54 <mlavalle> kevinbenton mentioned that he would like it to merge this cycle
15:52:08 <slaweq> patches for API and openvswitch are in review
15:52:12 <ralonsoh> slaweq has the API working
15:52:17 <mlavalle> I know
15:52:28 <ralonsoh> I'll help with OVS right now
15:52:38 <mlavalle> Just wanted you to knopw to be aware of that conversation
15:52:38 <ralonsoh> btw, SRIOV so far it's not possible
15:52:46 <ralonsoh> thanks!!
15:52:47 <slaweq> mlavalle: and I also want it to be merged :)
15:53:04 <ralonsoh> it's cool to know there is interest in that
15:53:17 <mlavalle> Last thing is next meeting will be during the Summit week, so I won't attend
15:53:24 <ralonsoh> no problem
15:53:32 <mlavalle> that's it. Thanks!
15:53:53 <slaweq> thx mlavalle for info
15:53:55 <ralonsoh> slaweq, the future of QoS depends on you!!!
15:54:01 <ralonsoh> hehehe
15:54:02 <mlavalle> it does
15:54:05 <slaweq> ralonsoh: ok :)
15:54:08 <mlavalle> no pressure!
15:54:11 <slaweq> I will do my best
15:54:18 <mlavalle> lol
15:54:19 <slaweq> mlavalle: of course :P
15:54:33 <ralonsoh> ok, guys, thank you very much
15:54:56 <ralonsoh> I'll end the meeting
15:54:57 <slaweq> thx
15:55:02 <davidsha> Thanks!
15:55:03 <mlavalle> o/
15:55:05 <ralonsoh> #endmeeting