17:16:57 #startmeeting ovn-community-development-discussion 17:16:58 Meeting started Thu Apr 30 17:16:57 2020 UTC and is due to finish in 60 minutes. The chair is mmichelson. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:16:59 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:17:01 The meeting name has been set to 'ovn_community_development_discussion' 17:17:45 Hello 17:18:07 hi 17:18:44 Let's get this thing started! 17:19:29 First off, I'd like to remind everyone that tomorrow is soft freeze for OVN 20.06. If you don't have patches for new features up by tomorrow, they'll need to wait. 17:19:53 Tomorrow, I'll send out an e-mail asking people which patches they would like to get merged in for the release of 20.06 17:19:58 <_lore_> hi all 17:20:24 Aside from that, I don't think I have anything to share right now. So whoever would like to go next, feel free. 17:21:36 I can go real quick 17:21:47 I did some code reviews this week. 17:21:54 And pushed out few patches. 17:22:20 1. I just rebased the I-P patches as they had some merge conflict (and hoping this would be pop up for review :)) 17:23:12 numans: so sorry for the delay of review. I was on some other issues. 17:23:13 2. Submitted a patch set to support OF1.5 in OVN and to support load balancer selection fields so tht CMS can decide whether to use dp_hash (which is default) or use hash with specified fields. 17:23:25 zhouhan, no worries. I understand :) 17:24:10 I also submitted one more patch to configure hwaddr for the br-int. The patch is here - https://patchwork.ozlabs.org/project/openvswitch/patch/20200430081000.751498-1-numans@ovn.org/ 17:24:23 That's it from me. 17:24:53 zhouhan, I've addressed the load balancer selection method here - https://patchwork.ozlabs.org/project/openvswitch/patch/20200430172028.1978594-1-numans@ovn.org/ 17:25:08 request to just go through the commit message. That should give an idea :) 17:25:16 and let me know if any issues with the approach. 17:25:35 Request everyone to take a look at the patches. 17:25:39 That's it from me. 17:26:01 numans: for 2), not sure if you saw the later discussions on the LB db_hash. I don't think we should switch to using hash instead of dp_hash. It would degrade the performance much. 17:26:25 zhouhan, I saw that. The default will be dp_hash 17:26:31 and it is left for the CMS to decide. 17:26:58 zhouhan, in the case of octavia lb algorithms there are 2 which we can support - IP_SOURCE and IP_SOURCE_PORT. 17:27:07 and its possible with this. 17:27:51 ok, I am ok with your patch that makes it flexible. But I mean the real problem here is the dp_hash implementation. And as imaximets pointed out it is already fixed upstream. 17:28:12 zhouhan, agree. 17:28:48 numans: and I am not sure when should we suggest user to use "hash" instead of "dp_hash". 17:28:55 zhouhan, it might take a while for the kernel patch to be backported to the distros. 17:29:03 in the meanwhile cms can use it. 17:29:11 People should be using bleeding edge at all times 17:29:15 zhouhan, I'd suggest user to use dp_hash. 17:29:30 mmichelson, :) 17:29:58 numans: if they use "hash", performance problems may be reported ... 17:30:17 zhouhan, agree. So its CMS's discretion. 17:30:29 zhouhan, I think we should document tht properly. 17:31:07 And I am also confused about the kernel patch backporting process. Is there anyone taking care of the backportings? What's the practices? 17:31:26 zhouhan, I mean it takes time for those patches to be in RHEL kernel for example 17:31:41 I'm not sure about ubuntu and other distros. 17:31:55 numans: Oh, ok. What I meant is backporting to OVS repo's datapath. 17:31:56 Yeah, Debian, RHEL, and CentOS are known for being late to the party 17:32:22 zhouhan, Ok. Most of the distros will have openvswitch kernel module in them 17:32:40 and RHEL uses the kernel openvswitch datapath 17:33:51 Ok. I'm done. If someone wants to go next. 17:33:52 numans: yes, but we have always been using the ones in OVS repo :) So I am really curious about the maintenance of that part. I thought it was always up-to-date. But this time it didn't happen automatically. 17:34:07 zhouhan, Ok. 17:34:32 hi all! sorry for joining late 17:34:37 at least blp should have the answer, but he seems to be absent for several weeks 17:34:50 zhouhan, from what I know, normally when the patch is merged in kernel, either the author will send it to ovs-dev ML 17:35:10 or someone from community posts the patch to ovs ML> 17:35:29 numans: ok, this time I pinged the author Tonghao Zhang, and he said he would help the backporting. 17:36:12 zhouhan, ack. I've one patch experience. I can post it if the author doesn't post :) 17:36:50 However, in my testing using fake-multi-node, the problem is solved even without the kernel patch. I didn't understand how. I will do some more investigation, maybe with a real server (instead of fake node) 17:37:16 I can keep on going with my report. 17:37:27 zhouhan, that's strange bcoz I used the fake-multi-node too and i was able to see the problem 17:37:35 :) 17:37:47 numans: using master? 17:37:53 zhouhan, yes. ovs master 17:38:01 and fedora 31 17:38:18 numans: hmm... that's really strange 17:38:43 Apart from the dp_hash invesitigation, I was chasing some other problems. 17:39:17 One of them is that Chassis-redirect-port doesn't work for ingress. 17:40:20 zhouhan, chassis-redirect-port .. its the distributed gw port with cr- right ? 17:42:27 When sending out a packet, the pipeline will redirect packet to the dedicated chassis to do the egress. However, if a packet is sent from LR1 to LR2 and a CRP on LR2 is the ingress port between LR1 to LR2, there is no redirection, and the packet is processed on the current chassis, and it gets dropped because in the admission stage the flows are missing due to the "chassis_resident" check. 17:42:36 numans: yes (cr-) 17:43:09 zhouhan, ok. 17:43:20 I will continue work on it. 17:43:24 that's it form me. 17:43:37 I can go next if that's ok 17:44:45 zhouhan, regarding the last patch series I sent to make ovn-northd work properly when ports are "moved" from one switch to another https://patchwork.ozlabs.org/project/openvswitch/list/?series=173823 17:45:15 zhouhan, it is something that we might see often with ovn-kubernetes when pods are "moved" from one node to another 17:45:44 zhouhan, because every node has its own logical switch 17:46:10 zhouhan, I think I can make it work so that stale port bindings are deleted instead of being reused but is that a must? 17:46:50 dceara: I see. I think it is better if we treat it as delete and create. 17:47:20 I agree with zhouhan. 17:47:29 this would ensure correctness. 17:47:55 zhouhan, ok, I need to think about other cases too (e.g., multicast_groups use tunnel_keys too) 17:48:11 but that should be fine. I'll try to post a v3 as soon as possible 17:48:12 From the logical network's point of view, port shouldn't move between switches. Also, even if the user would like to think so, it has to handle many other things like MAC conflict, etc. 17:48:56 zhouhan, I agree and ovn-kube is not trying to "move" the port, but just deletes the old one and adds a new one with the same name. That is a valid use case in my opinion. 17:50:09 dceara: yes, exactly. I think recreating a port with same name should be treated as deletion and recreation. 17:50:36 zhouhan, ok, i'll do it like that then 17:51:00 apart from that, I started on the v5 for the ovsdb-idl fix for monitor_cond_since. I have the code ready but didn't get a chance to test it yet. 17:51:17 that's it from me 17:51:33 dceara: thanks a lot. Looking forward to it 17:51:51 zhouhan, np 17:52:27 ok, maybe me? i'll be quick 17:52:58 so the multiple localnet ports series is now ready and validated by openstack folks that are primary consumers 17:53:01 https://patchwork.ozlabs.org/project/openvswitch/list/?series=173328 17:53:21 and I hope we can get it in the upcoming release, so reviews appreciated (thanks dceara for the prev round!) 17:53:35 ihrachys, noted! 17:53:41 ihrachys, thanks. I've downloaded the patches for review. 17:53:56 that's it for me. :) 17:54:09 ihrachys, np, I'll try to have another look soon too 17:54:18 * ihrachys bows 17:55:07 <_lore_> can I go next? very quick 17:55:59 <_lore_> this week I worked on adding some missing bits for IPv6 prefix delegation, low-hanging fruits actually 17:56:26 <_lore_> moreover I reposted the fix for qos meters in ovn addressing comments from zhouhan 17:56:51 The qos meters fix got merged, right? 17:56:55 <_lore_> I addressed comments from dceara in NetworkPolicy support for ovn-scale-test 17:56:57 _lore_: thanks, I will check 17:56:59 <_lore_> mmichelson: yep 17:57:07 <_lore_> zhouhan: not yet yours :( 17:57:38 <_lore_> Just fixed issues in the current approach, I need to extend it to load conf from a json file 17:58:05 _lore_: oh, ok. I was talking about the qos meter fix. But I just saw you mentioned it is merged. 17:58:06 <_lore_> maybe we can add it as a follow-up patch if the current version fixes the previous issues 17:58:32 <_lore_> zhouhan: yes, I just added unit-test respect to the previous one 17:58:52 great, thanks! 17:59:18 <_lore_> zhouhan: what do you think about address your comments as follow-up series? do you prefer to add them in the current one? 17:59:47 for ovn-scale-test? I am ok with a separate one. 18:00:13 <_lore_> ack, so I will check if there are some leftover issues from dceara 18:00:19 <_lore_> I hope I fixed them :) 18:00:27 <_lore_> thx, that's all from my side 18:00:38 OK. Anyone else? 18:00:44 _lore_, thanks, i'll have another look at your PR soon 18:01:24 <_lore_> ack, thx 18:03:02 All right. Thanks everyone! 18:03:04 #endmeeting