17:16:55 <numans> #startmeeting ovn-community-development-discussion
17:16:56 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:16:59 <openstack> The meeting name has been set to 'ovn_community_development_discussion'
17:17:09 <numans> Hello
17:17:25 <numans> mmichelson is not there today for the meeting
17:17:39 <numans> Who wants to start ?
17:18:03 <numans> I can
17:18:36 <numans> I'm working on handling the runtime data changes in the flow output stage
17:19:10 <numans> I'm still working on it and hoping to have thsee patches in v3 of the I-P patches next week
17:19:23 <blp> numans: Thanks for leading the meeting.
17:19:31 <numans> I did some code reviews as well
17:19:41 <numans> blp, welcome
17:19:45 <numans> That's it from me.
17:20:14 <blp> 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 <blp> 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 <numans> 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 <zhouhan> _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 <dceara> numans, may I go next?
17:25:46 <numans> dceara, sure
17:26:07 <dceara> 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 <zhouhan> thanks dceara for the great finding!
17:26:52 <dceara> 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 <dceara> zhouhan, my pleasure
17:27:59 <zhouhan> dceara: I am reviewing it. Just to confirm, this happens only when client connection lost temporarily, right?
17:28:18 <dceara> zhouhan, yes, indeed
17:29:08 <dceara> 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 <dceara> that's it from me, thanks!
17:30:08 <zhouhan> 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 <dceara> 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 <zhouhan> dceara: got it
17:31:50 <dceara> 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 <zhouhan> dceara: I will think about it. Maybe it is the best way. Thanks for your fix!
17:33:02 <dceara> zhouhan, the alternative is to be "reactive" and reconnect when the IDL detects the inconsistency. But that can happen quite late.
17:33:05 <dceara> zhouhan, thanks!
17:33:40 <zhouhan> but reconnect would also trigger the full download, right?
17:34:29 <dceara> 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 <zhouhan> dceara: ok, let's discuss in the review
17:35:37 <dceara> zhouhan, sounds good, thanks
17:35:47 * zhouhan don't have any update this time
17:36:20 <imaximets> may I go next?
17:36:39 <numans> sure
17:36:55 <imaximets> Just an update about the feature I working now.
17:37:07 <imaximets> 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 <imaximets> 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 <imaximets> 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 <imaximets> 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 <numans> imaximets, Sounds interesting.
17:38:21 <imaximets> 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 <imaximets> I have an almost working prototype with one small bug that I'm going to fix soon.
17:38:53 <imaximets> that's it from me.
17:39:32 <numans> Who wants to go next ?
17:40:04 <zhouhan> thanks imaximets. sounds interesting. Could you introduce a little about how do you record the events?
17:41:08 <imaximets> 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 <zhouhan> imaximets: does it impact performance when recording?
17:42:55 <imaximets> 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 <zhouhan> imaximets: got it, thanks!
17:43:45 <flaviof> may I drop in next?
17:44:10 <imaximets> 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 <zhouhan> imaximets: ok, sounds good!
17:47:07 <numans> I think we are done with this topic
17:47:16 <numans> flaviof, I think you can go next.
17:47:22 <flaviof> ty numans
17:47:27 <flaviof> 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 <flaviof> 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 <flaviof> That is all from me. And happy Easter to those of us who celebrate it!
17:48:23 <numans> flaviof, thanks. I saw the thread. I'll take a look tomorrow
17:48:39 <flaviof> TY!
17:49:09 <numans> zhouhan, In case you have some extra cycles, appreciate your comments on the v2 of I-P patch series.
17:50:47 <zhouhan> numans: oh, you mean the first 4 patches? I will do!
17:50:55 <zhouhan> numans: sorry for the delay
17:51:00 <numans> zhouhan, yes. Thanks. No worries
17:51:26 <numans> zhouhan, you've anything to report ?
17:51:39 <zhouhan> no updates this time :)
17:52:04 <numans> Ok. Is anyone else who wants to update ?
17:52:22 <numans> If not I think we can end the meeting a little early.
17:53:02 <blp> I don't ahve anything else.
17:53:22 <numans> Ok.
17:53:37 <numans> I think we can end.
17:53:43 <numans> Thanks everyone
17:53:46 <numans> Bye
17:53:51 <dceara> Bye
17:53:51 <zhouhan> thanks, bye
17:53:53 <flaviof> bye all!
17:53:54 <imaximets> bye
17:54:00 <numans> #endmeeting