15:00:07 #startmeeting neutron_qos 15:00:08 Meeting started Tue Mar 10 15:00:07 2020 UTC and is due to finish in 60 minutes. The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:09 o/ 15:00:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:12 The meeting name has been set to 'neutron_qos' 15:00:15 you can stay if you want here 15:00:24 :) 15:00:45 the agenda is very light today 15:01:18 so let's start 15:01:20 #topic RFEs 15:01:28 #link https://bugs.launchpad.net/neutron/+bug/1476527 15:01:32 Launchpad bug 1476527 in neutron "[RFE] Add common classifier resource" [Wishlist,Triaged] - Assigned to Igor D.C. (igordcard) 15:01:46 I'll send a mail to the ML to ask for developers 15:02:16 for now, this RFE is frozen 15:02:42 next one 15:02:43 #link https://bugs.launchpad.net/neutron/+bug/1858610 15:02:44 Launchpad bug 1858610 in neutron "[RFE] Qos policy not supporting sharing bandwidth between several nics of the same vm." [Undecided,New] 15:03:01 we agreed in the last drivers meeting to wait for a SPEC or POC 15:03:41 this feature is quite complex so a PoC could help to decide if the architecture change is correct 15:04:09 there are no more RFEs in the list 15:04:19 do you have something else to add here? 15:04:46 me? 15:04:50 hi! 15:04:53 Hey! 15:04:56 please, go on 15:06:03 davidsha, do you have something to add here? 15:06:14 I think they only way this could make sense to me is if it's applied at the instance, so it would need a lot of collaboration with Nova 15:06:48 davidsha, you mean to implement the QoS on the instance? 15:07:01 for this particular use case yes 15:07:13 but this is beyond the orchestrator 15:07:18 Otherwise you need a QoS rule thats an aggregate of specific ports 15:07:23 the orchestrator should not interfere on the instance 15:07:31 yes, that's the point 15:07:31 Ya 15:07:46 how this qos could be implemented in the backend 15:07:58 in LB they are proposing to use the IFB block 15:08:16 the same as I used (with no success) in the min BW implementation for LB 15:08:44 but as commented in the last drivers meeting, we'll wait for a spec/poc 15:09:03 So you need to change the typical relationship between rule -> policy -> port to rule wrapping multiple ports? 15:09:05 kk 15:09:17 yes, that's another topic 15:09:21 kk 15:09:36 more related to the server: how are you going to handle this new rule 15:09:49 just for the VM ports? for all the ports related to this rule? 15:09:57 nothing has been decided yet 15:09:58 ya, I''m thinking API at the moment 15:10:00 kk 15:11:05 ok, let's move to the next topic 15:11:10 #topic Bugs 15:11:15 #link https://bugs.launchpad.net/neutron/+bug/1866039 15:11:16 Launchpad bug 1866039 in neutron "[OVN] QoS gives different bandwidth limit measures than ml2/ovs" [High,In progress] - Assigned to Maciej Jozefczyk (maciej.jozefczyk) 15:11:44 I'm looking for the patch... 15:11:59 #link https://review.opendev.org/#/c/711048/ 15:12:13 there is a small transient measuring the BW 15:12:22 the BW at the beginning is higher 15:12:43 not to avoid but to reduce the impact of this transient on the average BW 15:12:59 kk 15:12:59 the file size to transfer will be proportional to the BW speed 15:13:20 this way, the transmission time will be always the same, 10 secs aprox 15:13:31 this will improve all backends 15:13:44 (will improve all backends tests) 15:13:58 please, review the patch 15:14:04 ack 15:14:09 next one 15:14:10 #link https://bugs.launchpad.net/neutron/+bug/1864630 15:14:11 Launchpad bug 1864630 in neutron "Hard Reboot VM with multiple port lost QoS " [Undecided,In progress] - Assigned to Nguyen Thanh Cong (congnt95) 15:14:29 I've +W the patch 1 hour ago 15:14:32 #link https://review.opendev.org/#/c/709687/ 15:14:48 good catch, thanks for reporting this bug 15:15:24 and now we have a series of bugs, all of them related 15:15:44 #link https://bugs.launchpad.net/neutron/+bug/1863987 15:15:45 Launchpad bug 1863987 in neutron "[OVN] Remove dependency on port_object" [Medium,In progress] - Assigned to zhanghao (zhanghao2) 15:15:49 #link https://bugs.launchpad.net/neutron/+bug/1863852 15:15:50 Launchpad bug 1863852 in neutron "[OVN]Could not support more than one qos rule in one policy" [Medium,In progress] - Assigned to Taoyunxiang (taoyunxiang) 15:15:55 #link https://bugs.launchpad.net/neutron/+bug/1862893 15:15:56 Launchpad bug 1862893 in neutron "[OVN]Updating a QoS policy for a port will cause a KeyEerror" [Low,In progress] - Assigned to zhanghao (zhanghao2) 15:16:30 the problem of those patches are that the patches are disconnected among them 15:16:40 we need to refactor the OVN QoS driver 15:17:07 to handle the QoS as a driver extension 15:17:23 we can't use the ML2 agent extension model because this is NOT an agent 15:17:39 I'm still working on this: https://review.opendev.org/#/c/711317/ 15:18:35 this patch will move the QoS handling to this new extension 15:18:49 the main problem I'm facing now is how to handle the QoS policy update 15:19:18 in the agents, the policies and the rules where stored in a in-memory mapping 15:19:33 but I'm very reluctant to do the same in the server 15:19:52 This is the Neutron server you're talking about? 15:19:52 in HA we can't guarantee this mapping will be shared between instances 15:19:56 yes 15:20:18 Neutron server has access to the DB, could you not pull from that? 15:20:21 Neutron server, sorry, in opposition to Neutron agent (sriov, LB, OVS) 15:20:26 that's the point 15:20:41 kk 15:20:49 we receive this call from the qos_plugin 15:20:55 self.driver_manager.call(qos_consts.UPDATE_POLICY, context, policy) 15:21:20 at this point, the policy (and the rules, this method is also called when a policy rule is updated) 15:21:30 stored in the DB is the new one 15:21:41 and we lost any track of the previous one... 15:22:03 Ok 15:22:09 --> how can we "delete" the OVN QoS registers if we don't have the information of the old policy and rules? 15:22:12 Iy's the delta you need to have 15:22:17 yes 15:22:41 and I'm squeezing my brain to find a solution 15:23:11 Is there some kind of history for modifications to DB objects that we can reference? 15:23:16 nope 15:23:21 :/ 15:24:23 anyway, I'll find something 15:24:51 Ya, OvN may need a mirror of the QoS tables. 15:25:12 I don't know if I can store this info in the OVN DB 15:25:39 no problem, I'll find something there 15:25:51 we still have another bug in the list 15:25:58 #link https://bugs.launchpad.net/networking-sfc/+bug/1853171 15:25:59 Launchpad bug 1853171 in neutron "Deprecate and remove any "ofctl" code in Neutron and related projects " [Medium,In progress] 15:26:06 davidsha, do you have any update? 15:26:40 Yes, I've had a go at the refactor, but I've run out of time: https://review.opendev.org/#/c/711949/ 15:27:07 no problem 15:27:20 once you stop working on this one, ping me 15:27:29 There seems to be some issue with ct_state and ct_mark, I'm not sure am I using it wrong, but the documentation implies it should work. 15:27:57 I'll try to reproduce it locally 15:28:44 The dynamic flow creation code in rules.py is only half migrated as well. 15:29:24 maybe this is going to be more complex than expected... 15:29:30 NXActions should be able to do conjunctions from what I read, I just haven't gotten that far to really know. 15:30:08 It shouldn't be too bad from here, my only concern is the ct_mark and ct_state issue, there could be a bug in Ryu and OS-Ken 15:30:42 It expects to recieve ints for those values, but the documentation says strings 15:31:48 do you know what part of the osken code is handling this? 15:32:54 I was looking at the code, I think it was in the 1.3 parser. the ct_state and ct_mark are part of nx_actions I believe? 15:33:40 https://github.com/openstack/os-ken/blob/9f1f1726d0b86a43df61bc22f6a8dec0f5c5b918/os_ken/ofproto/nicira_ext.py#L585 15:33:49 Ya it's listed as an int here 15:34:53 but you said before strings 15:35:03 https://github.com/openstack/os-ken/blob/9f1f1726d0b86a43df61bc22f6a8dec0f5c5b918/os_ken/tests/packet_data_generator3/gen.py#L111 15:35:04 Ya 15:35:25 CT_MARK_* are string 15:35:27 strings 15:35:42 hmmm maybe there you have your problem! 15:35:43 Ya 15:35:50 :P 15:36:07 So the constants need to be changed from strings to ints 15:36:19 to the corresponding ints* 15:36:29 maybe heheheh 15:36:49 I had to make a similar change for the ethertypes 15:37:14 They were being passed in as strings but needed to be ints @.@ 15:38:15 ping me once you have next version 15:39:01 Thats my last version I'm afraid :/ 15:39:16 ahhhh ok 15:39:27 I understand 15:39:29 sorry... 15:39:46 np, sorry I didn't get it all the way :P 15:40:40 ok, thanks a lot davidsha 15:41:05 do we have something else in the bug section? 15:41:22 #topic Open Discussion 15:41:30 I have nothing in the agenda 15:41:44 something to add here? 15:42:08 thank you all and see you in two weeks 15:42:10 #endmeeting