15:01:01 <ralonsoh> #startmeeting neutron_qos
15:01:02 <openstack> Meeting started Tue Feb 11 15:01:01 2020 UTC and is due to finish in 60 minutes.  The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:04 <ralonsoh> hi
15:01:06 <openstack> The meeting name has been set to 'neutron_qos'
15:01:07 <davidsha> o/
15:01:25 <ralonsoh> I don't think slawek is going to join us today
15:01:28 <davidsha> kk
15:01:37 <ralonsoh> let's wait 30 secs more
15:02:53 <ralonsoh> #topic RFEs
15:03:15 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1476527
15:03:16 <openstack> Launchpad bug 1476527 in neutron "[RFE] Add common classifier resource" [Wishlist,Triaged] - Assigned to Igor D.C. (igordcard)
15:03:20 <ralonsoh> davidsha, ^
15:04:23 <davidsha> Ya, I'm wrapping up the unit tests on the service plugin atm, however my team is being redeployed onto other tasks so I won't be able to continue development of the feature going forward.
15:05:18 <ralonsoh> davidsha, so are you going to stop the development of the feature?
15:05:56 <davidsha> ralonsoh: yesll post an update onto the patches so everyone is aware.
15:06:52 <ralonsoh> ok, I'll pack all the open patches in the bug
15:06:58 <ralonsoh> just to have them in a single place
15:07:16 <davidsha> thanks.
15:07:26 <ralonsoh> but I no one is going to continue the development, I don't think we should merge any of them
15:07:37 <ralonsoh> including the first one, the n-lib one
15:08:22 <davidsha> ack, I'll put a workflow -1 on the patches for the time being.
15:09:24 <ralonsoh> anyway, thank you very much for working in such a difficult feature
15:09:48 <ralonsoh> and if you are not going to work (for now) in OpenStack, thank you very much for your time
15:10:08 <ralonsoh> it was a pleasure to work with you  in the same team
15:10:21 <davidsha> thanks, and thank you for all the reviews and recommendations, I'll need to message Lajos aswell and thank them for the API test work
15:10:38 <davidsha> Thank you, the pleasure was all mine :)
15:11:17 <ralonsoh> ok, let's move then to the next RFE we have
15:11:23 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1858610
15:11:24 <openstack> Launchpad bug 1858610 in neutron "[RFE] Qos policy not supporting sharing bandwidth between several nics of the same vm." [Undecided,New]
15:11:53 <ralonsoh> we are still debating the in launchpad about the feasibility of this feature
15:12:11 <ralonsoh> we have 3 debating points
15:12:14 <davidsha> You would need to aggreagate all the ports is it?
15:12:31 <ralonsoh> that's one question
15:12:37 <ralonsoh> lest' start by
15:12:40 <ralonsoh> 1) the db model
15:12:53 <ralonsoh> this is the easiest one
15:13:08 <ralonsoh> to create a new qos rule, but this rule is exclusive with maxBW
15:13:25 <ralonsoh> a qos policy can have maxBW or maxBW shared
15:13:27 <ralonsoh> not both
15:13:53 <ralonsoh> (this must be defined with more detail in a spec)
15:13:58 <ralonsoh> 2) the neutron server
15:14:30 <ralonsoh> are we going to allow ports from different VMs with the same qos rule?
15:14:52 <ralonsoh> a rule can define how a port is scheduled?
15:15:33 <ralonsoh> IMO, we should NOT block a VM to be scheduled if a port has a shared maxBW rule and there are others ports, in different VMs, with this rule
15:15:45 <ralonsoh> in this case, the aggreagation is per VM level
15:16:09 <ralonsoh> and the shared BW will apply only for ports in the same VM with the same maxBW shared qos rule
15:16:34 <ralonsoh> (but this is just my opinion, no spec is defined yet)
15:16:38 <ralonsoh> davidsha, any comment?
15:17:11 <davidsha> ralonsoh, Just so I'm clear, is it a 1:1 mapping of Rule to VM to say all these ports with these rules are in the same VM?
15:17:54 <ralonsoh> no
15:17:58 <davidsha> with *this* rule are in the same VM*
15:18:00 <davidsha> kk
15:18:07 <ralonsoh> there is no 1:1 mapping between rule and VM
15:18:12 <ralonsoh> that's what I want to avoid
15:18:29 <davidsha> ack
15:18:41 <ralonsoh> if we do this, we need to create a placement resource provider to limit the port scheduling
15:18:53 <ralonsoh> and.... this is too much for this RFE
15:19:00 <ralonsoh> (just my opinion)
15:19:09 <davidsha> This nearly sounds like it should be a policy applied to the instance rather than the port.
15:19:30 <ralonsoh> you can have VMs with ports with the same rule
15:19:36 <ralonsoh> 1 maxBW shared rule
15:19:42 <ralonsoh> applied to 100 ports, 10 per VM
15:19:56 <ralonsoh> the 10 ports assigned to a VM will share the defined BW
15:20:10 <ralonsoh> of course, this must be enforced in the backend
15:20:16 <davidsha> yup
15:20:26 <ralonsoh> and this is the third point
15:20:29 <ralonsoh> 3) backend
15:20:58 <ralonsoh> 3.1) LB: similar to the proposal Jie is doing, but I would like to see more detail on this
15:22:06 <ralonsoh> 3.2) OVS: IMO, we **cannnot** introduce a LB in the middle of br-int and a device port
15:22:28 <ralonsoh> this won't work with DPDK or offload HW
15:22:56 <davidsha> with DPDK, probably not.
15:23:56 <ralonsoh> and that's why I would like Jie to propose a spec, to define those points
15:23:59 <davidsha> For OvS, it's QoS objects do let you route traffic into queues, I think it's only for egress traffic though
15:24:25 <ralonsoh> davidsha, you can make it work like in hybrid OVS
15:24:34 <davidsha> ack
15:24:39 <ralonsoh> with a LB in the middle of br-int and the VM
15:24:45 <davidsha> kk
15:24:48 <ralonsoh> and using the same strategy as in LB
15:24:52 <ralonsoh> but the performance...
15:25:04 <ralonsoh> and as I said, some compatibility issues
15:25:11 <davidsha> It's possible, just not practicle.
15:25:17 <ralonsoh> exactly
15:26:04 <ralonsoh> ok, let's move to next section
15:26:07 <ralonsoh> #topic Bugs
15:26:18 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1853171
15:26:20 <openstack> Launchpad bug 1853171 in neutron "Deprecate and remove any "ofctl" code in Neutron and related projects " [Medium,In progress] - Assigned to David Shaughnessy (david-shaughnessy)
15:26:33 <ralonsoh> as commented, this will take time
15:27:03 <davidsha> I'm looking into the firewall file at the moment, I'll try to push some initial work for it.
15:27:08 <ralonsoh> thanks!
15:27:17 <ralonsoh> no rush
15:27:43 <davidsha> ack
15:28:25 <ralonsoh> and the next one we have is
15:28:28 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1648525
15:28:29 <openstack> Launchpad bug 1648525 in neutron "[OVN] QoS doesn't work with DVR, vlan tenant networks or provider networks." [Undecided,New]
15:28:37 <ralonsoh> (filled in 2016)
15:28:42 <davidsha> :O
15:29:00 <ralonsoh> I'll talk to OVN guys to know more about this bug
15:29:12 <ralonsoh> and how to reproduce it
15:29:35 <ralonsoh> so far, I don't have more information about it
15:30:14 <ralonsoh> and that's all I have
15:30:20 <ralonsoh> #topic Open Discussion
15:30:32 <ralonsoh> do you have something for this section, davidsha ?
15:31:13 <davidsha> Just to thank everyone again, I enjoyed working with you all and hope to get the chance again!
15:31:20 <ralonsoh> for sure
15:31:28 <ralonsoh> thank you very much!
15:31:36 <ralonsoh> and see you around
15:31:48 <davidsha> See you!
15:32:09 <ralonsoh> bye
15:32:10 <ralonsoh> #endmeeting