17:16:55 #startmeeting ovn-community-development-discussion 17:16:56 Meeting started Thu Apr 9 17:16:55 2020 UTC and is due to finish in 60 minutes. The chair is numans. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:16:57 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:16:59 The meeting name has been set to 'ovn_community_development_discussion' 17:17:09 Hello 17:17:25 mmichelson is not there today for the meeting 17:17:39 Who wants to start ? 17:18:03 I can 17:18:36 I'm working on handling the runtime data changes in the flow output stage 17:19:10 I'm still working on it and hoping to have thsee patches in v3 of the I-P patches next week 17:19:23 numans: Thanks for leading the meeting. 17:19:31 I did some code reviews as well 17:19:41 blp, welcome 17:19:45 That's it from me. 17:20:14 I'm focusing on ddlog for ovn. I've more or less ignored ovs and ovn the last week. Probably annoying some people with that. Sorry. 17:20:42 I don't think I have more than that. 17:21:08 <_lore_> can I go next? 17:21:13 <_lore_> very quick 17:21:18 sure 17:21:38 <_lore_> this week I resumed my work on iPXE support in OVN adding new feature to dhcp support 17:22:02 <_lore_> moreover I am woring in ovn-scale-test adding OpenShift Network Policy support 17:22:42 <_lore_> zhouhan: it is based on my previous PR so when you have some free cycles could you please take a look to it? 17:22:51 <_lore_> thanks in advance 17:22:56 <_lore_> that's all from my side 17:23:17 _lore_: I feel real sorry that I still didn't review your previous PR. I will do it as soon as I can. 17:23:37 <_lore_> zhouhan: no worries 17:23:40 <_lore_> thanks 17:25:31 numans, may I go next? 17:25:46 dceara, sure 17:26:07 I sent a patch yesterday to fix the missing SB update issue I reported a few weeks ago: https://patchwork.ozlabs.org/patch/1268457/ 17:26:33 thanks dceara for the great finding! 17:26:52 It's due to a bug in the monitor_cond_since implementation. But I'm still a bit uncomfortable with the ovsdb-idl code so looking forward to reviews :) 17:27:28 zhouhan, my pleasure 17:27:59 dceara: I am reviewing it. Just to confirm, this happens only when client connection lost temporarily, right? 17:28:18 zhouhan, yes, indeed 17:29:08 also, I sent a series to backport all recent virtual port related fixes from OVN master/20.03 to OVS 2.12. It would be great if OVS committers could add them to 2.12 as we need them downstream: https://patchwork.ozlabs.org/project/openvswitch/list/?series=168987 17:29:56 that's it from me, thanks! 17:30:08 dceara: So, with the fix is it likely to trigger a storm of data downloading if many cilents lost connection and restored during a monitor-condition update. 17:31:10 zhouhan, the chance is higher. But it would happen only if the connection is lost exactly when the monitor-condition is updated. 17:31:39 dceara: got it 17:31:50 zhouhan, I couldn't think of a better way to deal with it. Especially because the client might reconnect to a different server (if running servers in raft) 17:32:45 dceara: I will think about it. Maybe it is the best way. Thanks for your fix! 17:33:02 zhouhan, the alternative is to be "reactive" and reconnect when the IDL detects the inconsistency. But that can happen quite late. 17:33:05 zhouhan, thanks! 17:33:40 but reconnect would also trigger the full download, right? 17:34:29 zhouhan, yes, it has to. Otherwise we might end up in a reconnect loop if the last-id txn is still in history. 17:35:30 dceara: ok, let's discuss in the review 17:35:37 zhouhan, sounds good, thanks 17:35:47 * zhouhan don't have any update this time 17:36:20 may I go next? 17:36:39 sure 17:36:55 Just an update about the feature I working now. 17:37:07 This is started as a performance test development for SB DB, but now I'm working on "stream-replay" functionality in OVS. 17:37:29 This is a new stream-provider and a bunch of hooks in the main stream.c that allows to record all the connections and data received on them to replay_* files in exact order as they are appearing in the lifetime of OVS-based process and actually replay them making, for example, ovsdb-server to think that it actually receives new connections and data while everything goes from the pre-recorded replay_* files. 17:37:48 This might be used for performance testing if you have recorded replays from your big setup and replaying them without any delays and sleeps between events just to check the raw performance of ovsdb-server. 17:38:05 This might also be used for root cause analysis in case you have recorded bad conditions and replaying them locally, maybe with debugger attached or more logs enabled. 17:38:20 imaximets, Sounds interesting. 17:38:21 Since implementation is on a "stream" level, this will record all the db connections, openflow and unixctl. ovsdb-server is a good application to record because it has no other sources of events beside stream. ovn-controller might be also a good candidate. 17:38:36 I have an almost working prototype with one small bug that I'm going to fix soon. 17:38:53 that's it from me. 17:39:32 Who wants to go next ? 17:40:04 thanks imaximets. sounds interesting. Could you introduce a little about how do you record the events? 17:41:08 zhouhan, I have a file for each passive and active stream. File has records. Each record is a global sequence number, length and the actual received data. 17:41:55 imaximets: does it impact performance when recording? 17:42:55 zhouhan, you could look at the prototype at https://github.com/igsilya/ovs/tree/tmp-stream-replay if you want deep details. But sure it will impact performance by the fact that each received buffer is written to file. 17:43:12 imaximets: got it, thanks! 17:43:45 may I drop in next? 17:44:10 zhouhan, but actual receiving/sending data is not a bottleneck in ovsdb, so I hope that it will not degrade performance too much. 17:44:32 imaximets: ok, sounds good! 17:47:07 I think we are done with this topic 17:47:16 flaviof, I think you can go next. 17:47:22 ty numans 17:47:27 I don't have anything worth mentioning this week, again. 😜 But would like to chime in on behalf of Maciej on this discussion: https://mail.openvswitch.org/pipermail/ovs-discuss/2020-April/049896.html 17:47:35 Not sure if any of you have had experience with using selection_method=dp_hash in Openflow, but if you did and have an understanding of how OVN is supposed to interact with that, please respond to that thread. 17:47:49 That is all from me. And happy Easter to those of us who celebrate it! 17:48:23 flaviof, thanks. I saw the thread. I'll take a look tomorrow 17:48:39 TY! 17:49:09 zhouhan, In case you have some extra cycles, appreciate your comments on the v2 of I-P patch series. 17:50:47 numans: oh, you mean the first 4 patches? I will do! 17:50:55 numans: sorry for the delay 17:51:00 zhouhan, yes. Thanks. No worries 17:51:26 zhouhan, you've anything to report ? 17:51:39 no updates this time :) 17:52:04 Ok. Is anyone else who wants to update ? 17:52:22 If not I think we can end the meeting a little early. 17:53:02 I don't ahve anything else. 17:53:22 Ok. 17:53:37 I think we can end. 17:53:43 Thanks everyone 17:53:46 Bye 17:53:51 Bye 17:53:51 thanks, bye 17:53:53 bye all! 17:53:54 bye 17:54:00 #endmeeting