On 3/3/26 10:21 AM, Xavier Simonart via dev wrote: > If a server unexpectedly rebooted, OVS, when restarted, sets BFD > UP on bfd-enabled geneve tunnels. > However, if it takes time to restart OVN, an HA gw chassis > would attract the traffic while being unable to handle it > (as no flows), resulting in traffic loss. > > This is fixed by re-using ovs flow-restore-wait. > If set, OVS waits (prevents upcalls, ignores bfd, ...) until reset. > Once OVS receives the notification of flow-restore-wait being false, > it restarts handling upcalls, bfd... and ignores any new change to > flow-restore-wait. > > Hence OVN toggles flow-restore-wait: set it to false, waits for ack > from OVS and then sets it back to true. > If server reboots, OVS will see flow-restore-wait being true. > > "ovs-ctl restart" also uses flow-restore-wait. > So OVS will wait either "ovs-ctl restart" or OVN sets flow-restore-wait > to false. > > Reported-at: https://issues.redhat.com/browse/FDP-3075 > Signed-off-by: Xavier Simonart <[email protected]> > --- > controller/ovn-controller.c | 133 +++++++++- > tests/multinode-macros.at | 22 ++ > tests/multinode.at | 504 ++++++++++++++++++++++++------------ > 3 files changed, 488 insertions(+), 171 deletions(-)
Hi, Xavier and Mark. I haven't looked at the code, but I have a concern about this change. If we go this way, then ovn-controller will not be able to become a primary controller and will be stuck using the service connection (br-int.mgmt) as it does today. This is because primary controller is not allowed while flow-restore-wait is set. So, on node reboot OVS will get stuck with no flows as ovn-ctl will not clear the flag and OVS will not allow ovn-controller to connect. And upgrading from a version of ovn-controller that sets flow-restore-wait and uses a service connection to a version that is a primary controller will likely be problematic. ovn-controller abusing the service connection has a few issues that came up multiple times in the past: 1. Service connection is not configurable. E.g. it's not possible to set inactivity probe interval. It's always the default 60 seconds. It means that full recompute can never be longer than 120 seconds in ovn-controller. Otherwise it gets into an infinite reconnect + recompute loop. This is a common issue that people run into at high scale. 2. There is a race between ovn-controller and ovs-ctl for configuring OpenFlow. When ovs-ctl restarts OVS: - It saves the flows and other configuration. - It sets flow-restore-wait. - Restarts the OVS deamon. - Configures all the OpenFlow stuff back via the service connection. - Removes the flow-restore-wait. However, since ovn-controller is not a primary controller, it also connects to OVS via the service connection and starts programming flows and tunnel metadata and other things messing up the config and also breaking ovs-ctl that would bail if one of the restoration commands fails. This issue actually happened in OpenStack in the past. 3. There is no good way to get statistics for the OpenFlow connection, because statistics for the service connection is not exposed through the database. What we could do instead is to make ovn-controller a primary controller first and extend the flow-restore-wait mechanism in OVS to have a mode where primary controllers are allowed (switch it from boolean to a enum true/false/controller), so it can be used by ovn-controller without messing with the standard ovs-ctl. We discussed the approach off-list some time ago. Why did you choose not to go with it? Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
