17:21:40 #startmeeting ovn_community_development_discussion 17:21:41 Meeting started Thu Oct 15 17:21:40 2020 UTC and is due to finish in 60 minutes. The chair is mmichelson. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:21:42 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:21:44 The meeting name has been set to 'ovn_community_development_discussion' 17:22:11 I can start things off, but there's not much for me to report. 17:22:11 Hi 17:22:37 Biggest time sink of mine this week has been reviews. I still have more in my queue to look at 17:23:06 I'm also writing up a post that will hopefully go on the OVN website that gives an overview of changes in 20.09 17:23:26 Nothing too deep, but more than just what's in the NEWS file. 17:23:40 And that's all for me to report 17:26:43 I have a very little update. 17:27:19 This week I tried to run OVN tests with clang MemorySanitizer and found on issue with ic. 17:27:51 It hashes struct v46_ip with uninitialized memory inside. 17:27:52 I think I saw a patch from Han with a fix for that 17:28:22 Yep, I sent a bug report to maillist and zhouhan sent a patch for this. 17:28:53 That's it from my side for OVN this week. 17:29:05 <_lore_> hi all 17:29:28 <_lore_> can I go next? 17:29:32 <_lore_> very quick 17:29:36 go for it 17:29:39 <_lore_> this week I posted: 17:29:47 <_lore_> 1- iPXE support for ovn 17:29:57 <_lore_> tested by OSP folks 17:30:11 <_lore_> 2- Renew/Rebind support for IPv6 PD 17:30:45 <_lore_> 3- now I stared working on a BFD implementation in OVN to enable link failure detection for emcp routing 17:30:53 <_lore_> that's all from my side 17:31:44 I have a quick update too if I may go next. 17:32:22 yeah I like these quick updates :) 17:32:46 Thanks to zhouhan and Mark Gray for reviews on the ofctrl predictable conflict resolution patches! I sent a v6 and today a v7: http://patchwork.ozlabs.org/project/ovn/patch/1602753150-31918-1-git-send-email-dceara@redhat.com/ 17:33:11 dceara: thank you! I am reviewing now. 17:33:30 zhouhan: Sorry, I think we had some confusion at some point, but I hope it's all sorted out now. 17:34:17 Except for that I did some reviews this week and I wanted to bring up to attention numans' question on patch http://patchwork.ozlabs.org/project/ovn/patch/20201014091525.3391981-1-numans@ovn.org/ 17:35:01 That's it from my side, thanks! 17:35:10 dceara, thanks for bringing it up. 17:35:25 numans: I didn't know if you'd join :) 17:35:26 I can go real quick too. 17:35:32 * numans just joined 17:36:09 It would be great if mmichelson zhouhan and others can provide their comments to the link dceara shared. 17:36:32 based on that, I'll spin up next version of reject patch series. 17:36:50 numans: is the question about whether we should swap IPs and ETHs together? 17:36:54 other than that I worked for reducing the hairpin flows. 17:37:14 zhouhan, yes 17:37:32 zhouhan, or versus whether to go another ovn field ip.src <-> ip.dst 17:37:46 which results in another packet-in. 17:38:14 numans, I'll have a look after this meeting. 17:38:21 mmichelson, thanks. 17:38:24 another packet-in sounds bad :( 17:38:52 yeah the issue is that the ip.src <-> ip.dst results in a packet in, and then the reject {} does a second packet in. 17:38:57 zhouhan, which means we need to swap eth src and eth dst and ip src and ip dst 17:39:16 mmichelson, zhouhan FYI we do the same for icmp4.frag_mtu too 17:40:08 numans: you mean two packet-ins for frag_mtu? 17:40:17 I'm fine to implicitly swap these fields in reject pkt-in, but normally in OVN, we specify the inner actions to any OVN action 17:40:45 zhouhan, the usage of it is - icmp4 { eth.src <-> eth.dst ,...., icmp4.frag_mtu = 1500 ...} 17:40:53 zhouhan, this results in packetin for icmp4 action 17:41:11 numans: In my opinion "reject" is explicit enough to imply that it will generate a packet with addresses swapped. 17:41:13 and then again to set icmp4.frag_mtu (with pause flag set for this one) 17:41:33 zhouhan, that was suggested by Ben when I worked on it while back 17:42:10 I'm fine with both the approaches. I'll respin the patches based on the comments :) 17:42:29 That's it from my side. 17:42:31 numans: thanks for the information. I will check it offline. 17:42:43 zhouhan, welcome 17:43:04 May I go next? 17:43:27 I want to briefly discuss the _is_new problem, if Mark Gray is here? 17:44:26 Hm, if he's in here he's using a nick I'm not familiar with 17:44:38 dceara: thanks for sharing the code that relies on _is_new() for a row inserted in current transaction 17:45:09 dceara: I think there is some confusion for those interfaces _is_new(), _is_modified() ... 17:45:44 zhouhan: I agree. But we do use them for locally inserted records too. We could make them work in that case too. Which is what Mark's patch does, IIUC. 17:45:52 dceara: for my understanding these are for tracked changes only. But it seems it is used for checking a row added in current transaction (not committed yet) 17:46:22 dceara: yes, it is definitely possible to change it. 17:47:03 zhouhan: I think the patch will not break the tracked changes functionality so I think it would be good to have. 17:47:35 dceara: but if we change, we should make sure it is changed for modify and delete, not only just for insert. (I am not 100% sure if there is any potential problems, need to study more on this) 17:47:40 But I'm not extremely familiar with that code so I might be wrong. 17:48:18 zhouhan: OK, I see. 17:48:35 dceara: let's check more and discuss with Mark Gray. 17:48:45 zhouhan: Ack. 17:49:00 I don't have any other updates except the bug fix and some reviews 17:49:05 thanks 17:50:51 Okie-dokie. Anyone else have updates? 17:52:25 I guess that's it then. Thanks everyone! 17:52:28 #endmeeting