On 3/8/23 08:57, Frode Nordahl wrote: >>>> Does it state that configuring inactivity probe on the DB cluster side >>>> will not help and configuration on the relay side must be done? >> >> Yes. You likely need a configuration on the relay side. > > Sorry for butting into an ongoing discussion, but this part resonated > with one of my past ventures. While investigating a different problem > we kind of hit a similar problem [0]. Aligning client, relay and > backend server configuration has potential to become complicated. > Would an alternative be for the real server and relay server to > exchange this information in-line as part of their communication, for > example exposing it in the special _Server built-in database [1]? > > 0: > https://bugs.launchpad.net/ubuntu/lunar/+source/openvswitch/+bug/1998781/comments/3 > 1: https://github.com/openvswitch/ovs/blob/master/ovsdb/_server.ovsschema >
Hi, Frode. Do you mean synchronizing probes for passive connections, i.e. having ptcp/pssl remotes with the same inactivity probes on the main DB and relay? Or making <relay> --> <main DB> connection have the same probe interval as passive <main DB> --> <relay> connection? The main problem with the former I see is that it is currently configurable for each side individually. And it would be confusing if ovsdb-server will override the user-specified value. Hence, the config knob, i.e. configuration by the user, will be needed anyway. The latter is basically some form of what Wentao Jia proposed [2]. We could do something like that, since there is no way to configure the probe interval in <relay> --> <main DB> direction at the moment. But that that will be different from any other connection we have in OVS world, so may complicate the understanding of the matter even more. I hope that we can forget about <client> --> <server> inactivity probes at some point and just use the default. We do control the server and we can make it faster / operate better. In fact, we do not see any large poll intervals in large scale ovn-heater tests on neither Sb nor Nb OVSDB servers, not even 1 second long, with recent OVS versions. Remaining cases I'm aware of are associated with the database conversion and potential mass re-connections, which are both solvable and being worked at. The opposite <server> --> <client> direction is a bit more problematic, because we do not control the client application, so we don't know how long it may not reply. E.g. full recompute on ovn-controller may still take a lot of time. But perhaps we could just bump the default probe interval for this direction to something like 60 seconds or even more. Checking if the client is alive isn't really that important for a server, we just need to disconnect dead clients eventually. [2] https://patchwork.ozlabs.org/project/openvswitch/patch/an2a4qcpihpcfukyt1uomqre.1.1641782536691.hmail.wentao....@easystack.cn/ Best regards, Ilya Maximets. _______________________________________________ discuss mailing list disc...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
