Re: [ovs-dev] [PATCH ovn v3] controller: Fix bfd up too early after unexpected reboot.
Hi Dumitru On Tue, Mar 31, 2026 at 11:44 AM Dumitru Ceara wrote: > Hi Xavier, > > On 3/30/26 4:43 PM, Dumitru Ceara wrote: > > On 3/30/26 3:54 PM, Dumitru Ceara wrote: > >>> I see, thanks for the detailed walk through! > >>> > >>> Acked-by: Dumitru Ceara > >>> > >>> I'll wait with merging this until next week in case Mark wants to have > a > >>> look at this new version too. > >>> > >> I went ahead and applied this patch to the main branch. > >> > > > > I forgot to mention: I am planning to backport this to stable branches, > > I just didn't get a chance to do it yet. > > > > I backported this patch to 26.03 and 25.09. I wanted to go further and > backport to 25.03, 24.09 and 24.03 too but there are some issues: > > - the multinode tests don't really work on 25.03 and later - not related > to this patch but I'd prefer if we could have test coverage there too. I > guess we need a custom patch on those branches to fix up the CI (it's > trying to build 22.03 now as a base image) > > - conflicts that make it a non trivial backport to 24.09 and 24.03 > > Xavier, would you happen to have some time to work on these things? > Especially the custom fix patches to 24.09 and 24.03. > I'll take care of that. > > For the multinode tests on 25.03 and later I can try to find some time > to fix them if you don't have free cycles. > I'll also look into it and try to provide customer patches for 25.03, 24.09 and 24.03. > > Thanks, > Dumitru > Thanks Xavier ___ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v3] controller: Fix bfd up too early after unexpected reboot.
Hi Xavier, On 3/30/26 4:43 PM, Dumitru Ceara wrote: > On 3/30/26 3:54 PM, Dumitru Ceara wrote: >>> I see, thanks for the detailed walk through! >>> >>> Acked-by: Dumitru Ceara >>> >>> I'll wait with merging this until next week in case Mark wants to have a >>> look at this new version too. >>> >> I went ahead and applied this patch to the main branch. >> > > I forgot to mention: I am planning to backport this to stable branches, > I just didn't get a chance to do it yet. > I backported this patch to 26.03 and 25.09. I wanted to go further and backport to 25.03, 24.09 and 24.03 too but there are some issues: - the multinode tests don't really work on 25.03 and later - not related to this patch but I'd prefer if we could have test coverage there too. I guess we need a custom patch on those branches to fix up the CI (it's trying to build 22.03 now as a base image) - conflicts that make it a non trivial backport to 24.09 and 24.03 Xavier, would you happen to have some time to work on these things? Especially the custom fix patches to 24.09 and 24.03. For the multinode tests on 25.03 and later I can try to find some time to fix them if you don't have free cycles. Thanks, Dumitru ___ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v3] controller: Fix bfd up too early after unexpected reboot.
On 3/30/26 3:54 PM, Dumitru Ceara wrote: >> I see, thanks for the detailed walk through! >> >> Acked-by: Dumitru Ceara >> >> I'll wait with merging this until next week in case Mark wants to have a >> look at this new version too. >> > I went ahead and applied this patch to the main branch. > I forgot to mention: I am planning to backport this to stable branches, I just didn't get a chance to do it yet. Regards, Dumitru ___ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [PATCH ovn v3] controller: Fix bfd up too early after unexpected reboot.
On 3/27/26 2:40 PM, Dumitru Ceara wrote:
> On 3/27/26 2:31 PM, Xavier Simonart wrote:
>> Hi Dumitru
>>
>
> Hi Xavier,
>
>> Thanks again for looking at this.
>>
>> On Fri, Mar 27, 2026 at 12:38 PM Dumitru Ceara wrote:
>>
>>> On 3/26/26 5:16 PM, Xavier Simonart 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, on chassis hosting ha gateways, OVN toggles flow-restore-wait:
it 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.
OVN also sets external_ids->ovn-managed-flow-restore-wait when setting
flow-restore-wait. When set, it tells that OVN once set
>>> flow-restore-wait.
"ovs-ctl restart" also uses flow-restore-wait: when called, it saves the
flows, stops "ovs-vswitchd", sets "flow-restore-wait" to true, restarts
"ovs-vswitchd", restores the flows and finally removes
>>> "flow-restore-wait".
So OVS will wait either for "ovs-ctl restart" to remove
>>> "flow-restore-wait"
or for OVN to set "flow-restore-wait" to false.
Reported-at: https://issues.redhat.com/browse/FDP-3075
Signed-off-by: Xavier Simonart
---
-v2 : - Updated based on Mark's feedback (commit message, comments).
- Avoid setting flow-restore-wait for computes.
- Add external_ids->ovn-managed-flow-restore-wait.
- Updated test: add test for compute update + nits (variable name
>>> changes)
-v3 : - Fix test failing on CI (using wrong host socket)
- Address nits from Dumitru + few more nits (related to comments).
- Increased tolerated loss (and add comment) to avoid flakiness.
- Rebased.
---
>>>
>>> Hi Xavier,
>>>
>>> Thanks for the v3!
>>>
>
> [...]
>
+
+static void
+manage_flow_restore_wait(struct ovsdb_idl_txn *ovs_idl_txn,
+ const struct ovsrec_open_vswitch *cfg,
+ uint64_t ofctrl_cur_cfg, uint64_t ovs_next_cfg,
+ int ovs_txn_status, bool is_ha_gw)
+{
+enum flow_restore_wait_state {
+FRW_INIT, /* Initial state */
+FRW_WAIT_TXN_COMPLETE, /* Sent false, waiting txn to complete */
+FRW_TXN_SUCCESS, /* Txn completed. Waiting for OVS Ack. */
+FRW_DONE /* Everything completed */
+};
+
+static int64_t frw_next_cfg;
+static enum flow_restore_wait_state frw_state;
+static bool ofctrl_was_connected = false;
+
+bool ofctrl_connected = ofctrl_is_connected();
+
+if (!ovs_idl_txn || !cfg) {
+return;
+}
+
+/* If OVS is stopped/started, make sure flow-restore-wait is
>>> toggled. */
+if (ofctrl_connected && !ofctrl_was_connected) {
+frw_state = FRW_INIT;
+}
+ofctrl_was_connected = ofctrl_connected;
+
+if (!ofctrl_connected) {
+return;
+}
+
+bool frw = smap_get_bool(&cfg->other_config, "flow-restore-wait",
>>> false);
+bool ovn_managed_once = smap_get_bool(&cfg->external_ids,
+
>>> "ovn-managed-flow-restore-wait",
+ false);
+
+if (frw && !ovn_managed_once) {
+/* frw has been set by ovs-ctl. Do not touch. */
+return;
+}
+
+if (!is_ha_gw) {
+if (frw) {
+/* frw has once been set by OVN. We are now not an HA
>>> chassis
+ * anymore, unset it. */
+set_flow_restore_wait(ovs_idl_txn, cfg, &cfg->other_config,
+ false, ovn_managed_once);
+}
+/* else we are not an HA chassis and frw is false. Ignore it. */
+return;
+}
+
+switch (frw_state) {
+case FRW_INIT:
+if (ofctrl_cur_cfg > 0) {
+set_flow_restore_wait(ovs_idl_txn, cfg, &cfg->other_config,
+ false, ovn_managed_once);
+frw_state = FRW_WAIT_TXN_COMPLETE;
+VLOG_INFO("Setting flow-restore-wait=false "
+ "(cur_cfg=%"PRIu64")", ofctrl_cur_cfg);
+}
+break;
+
+case FRW_WAIT_TXN_COMPLETE:
Re: [ovs-dev] [PATCH ovn v3] controller: Fix bfd up too early after unexpected reboot.
On 3/27/26 2:31 PM, Xavier Simonart wrote:
> Hi Dumitru
>
Hi Xavier,
> Thanks again for looking at this.
>
> On Fri, Mar 27, 2026 at 12:38 PM Dumitru Ceara wrote:
>
>> On 3/26/26 5:16 PM, Xavier Simonart 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, on chassis hosting ha gateways, OVN toggles flow-restore-wait:
>>> it 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.
>>>
>>> OVN also sets external_ids->ovn-managed-flow-restore-wait when setting
>>> flow-restore-wait. When set, it tells that OVN once set
>> flow-restore-wait.
>>>
>>> "ovs-ctl restart" also uses flow-restore-wait: when called, it saves the
>>> flows, stops "ovs-vswitchd", sets "flow-restore-wait" to true, restarts
>>> "ovs-vswitchd", restores the flows and finally removes
>> "flow-restore-wait".
>>> So OVS will wait either for "ovs-ctl restart" to remove
>> "flow-restore-wait"
>>> or for OVN to set "flow-restore-wait" to false.
>>>
>>> Reported-at: https://issues.redhat.com/browse/FDP-3075
>>> Signed-off-by: Xavier Simonart
>>>
>>> ---
>>> -v2 : - Updated based on Mark's feedback (commit message, comments).
>>> - Avoid setting flow-restore-wait for computes.
>>> - Add external_ids->ovn-managed-flow-restore-wait.
>>> - Updated test: add test for compute update + nits (variable name
>> changes)
>>> -v3 : - Fix test failing on CI (using wrong host socket)
>>> - Address nits from Dumitru + few more nits (related to comments).
>>> - Increased tolerated loss (and add comment) to avoid flakiness.
>>> - Rebased.
>>> ---
>>
>> Hi Xavier,
>>
>> Thanks for the v3!
>>
[...]
>>> +
>>> +static void
>>> +manage_flow_restore_wait(struct ovsdb_idl_txn *ovs_idl_txn,
>>> + const struct ovsrec_open_vswitch *cfg,
>>> + uint64_t ofctrl_cur_cfg, uint64_t ovs_next_cfg,
>>> + int ovs_txn_status, bool is_ha_gw)
>>> +{
>>> +enum flow_restore_wait_state {
>>> +FRW_INIT, /* Initial state */
>>> +FRW_WAIT_TXN_COMPLETE, /* Sent false, waiting txn to complete */
>>> +FRW_TXN_SUCCESS, /* Txn completed. Waiting for OVS Ack. */
>>> +FRW_DONE /* Everything completed */
>>> +};
>>> +
>>> +static int64_t frw_next_cfg;
>>> +static enum flow_restore_wait_state frw_state;
>>> +static bool ofctrl_was_connected = false;
>>> +
>>> +bool ofctrl_connected = ofctrl_is_connected();
>>> +
>>> +if (!ovs_idl_txn || !cfg) {
>>> +return;
>>> +}
>>> +
>>> +/* If OVS is stopped/started, make sure flow-restore-wait is
>> toggled. */
>>> +if (ofctrl_connected && !ofctrl_was_connected) {
>>> +frw_state = FRW_INIT;
>>> +}
>>> +ofctrl_was_connected = ofctrl_connected;
>>> +
>>> +if (!ofctrl_connected) {
>>> +return;
>>> +}
>>> +
>>> +bool frw = smap_get_bool(&cfg->other_config, "flow-restore-wait",
>> false);
>>> +bool ovn_managed_once = smap_get_bool(&cfg->external_ids,
>>> +
>> "ovn-managed-flow-restore-wait",
>>> + false);
>>> +
>>> +if (frw && !ovn_managed_once) {
>>> +/* frw has been set by ovs-ctl. Do not touch. */
>>> +return;
>>> +}
>>> +
>>> +if (!is_ha_gw) {
>>> +if (frw) {
>>> +/* frw has once been set by OVN. We are now not an HA
>> chassis
>>> + * anymore, unset it. */
>>> +set_flow_restore_wait(ovs_idl_txn, cfg, &cfg->other_config,
>>> + false, ovn_managed_once);
>>> +}
>>> +/* else we are not an HA chassis and frw is false. Ignore it. */
>>> +return;
>>> +}
>>> +
>>> +switch (frw_state) {
>>> +case FRW_INIT:
>>> +if (ofctrl_cur_cfg > 0) {
>>> +set_flow_restore_wait(ovs_idl_txn, cfg, &cfg->other_config,
>>> + false, ovn_managed_once);
>>> +frw_state = FRW_WAIT_TXN_COMPLETE;
>>> +VLOG_INFO("Setting flow-restore-wait=false "
>>> + "(cur_cfg=%"PRIu64")", ofctrl_cur_cfg);
>>> +}
>>> +break;
>>> +
>>> +case FRW_WAIT_TXN_COMPLETE:
>>> +/* if (ovs_idl_txn != NULL), the transaction completed.
>>> + * When the transaction completed, it either failed
>>> + * (ovs_txn_status == 0) or succee
Re: [ovs-dev] [PATCH ovn v3] controller: Fix bfd up too early after unexpected reboot.
Hi Dumitru
Thanks again for looking at this.
On Fri, Mar 27, 2026 at 12:38 PM Dumitru Ceara wrote:
> On 3/26/26 5:16 PM, Xavier Simonart 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, on chassis hosting ha gateways, OVN toggles flow-restore-wait:
> > it 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.
> >
> > OVN also sets external_ids->ovn-managed-flow-restore-wait when setting
> > flow-restore-wait. When set, it tells that OVN once set
> flow-restore-wait.
> >
> > "ovs-ctl restart" also uses flow-restore-wait: when called, it saves the
> > flows, stops "ovs-vswitchd", sets "flow-restore-wait" to true, restarts
> > "ovs-vswitchd", restores the flows and finally removes
> "flow-restore-wait".
> > So OVS will wait either for "ovs-ctl restart" to remove
> "flow-restore-wait"
> > or for OVN to set "flow-restore-wait" to false.
> >
> > Reported-at: https://issues.redhat.com/browse/FDP-3075
> > Signed-off-by: Xavier Simonart
> >
> > ---
> > -v2 : - Updated based on Mark's feedback (commit message, comments).
> > - Avoid setting flow-restore-wait for computes.
> > - Add external_ids->ovn-managed-flow-restore-wait.
> > - Updated test: add test for compute update + nits (variable name
> changes)
> > -v3 : - Fix test failing on CI (using wrong host socket)
> > - Address nits from Dumitru + few more nits (related to comments).
> > - Increased tolerated loss (and add comment) to avoid flakiness.
> > - Rebased.
> > ---
>
> Hi Xavier,
>
> Thanks for the v3!
>
> > controller/bfd.c| 5 +-
> > controller/bfd.h| 4 +-
> > controller/ovn-controller.8.xml | 11 +
> > controller/ovn-controller.c | 173 +-
> > tests/multinode-macros.at | 46 +++
> > tests/multinode.at | 548 ++--
> > 6 files changed, 612 insertions(+), 175 deletions(-)
> >
> > diff --git a/controller/bfd.c b/controller/bfd.c
> > index 3b0c3f6da..56bfa4936 100644
> > --- a/controller/bfd.c
> > +++ b/controller/bfd.c
> > @@ -117,13 +117,14 @@ bfd_calculate_active_tunnels(const struct
> ovsrec_bridge *br_int,
> > *
> > * If 'our_chassis' is C5 then this function returns empty bfd set.
> > */
> > -void
> > +bool
> > bfd_calculate_chassis(
> > const struct sbrec_chassis *our_chassis,
> > const struct sbrec_ha_chassis_group_table *ha_chassis_grp_table,
> > struct sset *bfd_chassis)
> > {
> > const struct sbrec_ha_chassis_group *ha_chassis_grp;
> > +bool chassis_is_ha_gw = false;
> > SBREC_HA_CHASSIS_GROUP_TABLE_FOR_EACH (ha_chassis_grp,
> > ha_chassis_grp_table) {
> > bool is_ha_chassis = false;
> > @@ -143,6 +144,7 @@ bfd_calculate_chassis(
> > sset_add(&grp_chassis, ha_ch->chassis->name);
> > if (our_chassis == ha_ch->chassis) {
> > is_ha_chassis = true;
> > +chassis_is_ha_gw = true;
> > bfd_setup_required = true;
> > }
> > }
> > @@ -178,6 +180,7 @@ bfd_calculate_chassis(
> > }
> > sset_destroy(&grp_chassis);
> > }
> > +return chassis_is_ha_gw;
> > }
> >
> > void
> > diff --git a/controller/bfd.h b/controller/bfd.h
> > index f8fece5a5..3e3384891 100644
> > --- a/controller/bfd.h
> > +++ b/controller/bfd.h
> > @@ -16,6 +16,8 @@
> > #ifndef OVN_BFD_H
> > #define OVN_BFD_H 1
> >
> > +#include
> > +
> > struct hmap;
> > struct ovsdb_idl;
> > struct ovsdb_idl_index;
> > @@ -36,7 +38,7 @@ void bfd_run(const struct ovsrec_interface_table *,
> > const struct sbrec_sb_global_table *,
> > const struct ovsrec_open_vswitch_table *);
> >
> > -void bfd_calculate_chassis(
> > +bool bfd_calculate_chassis(
> > const struct sbrec_chassis *,
> > const struct sbrec_ha_chassis_group_table *,
> > struct sset *);
> > diff --git a/controller/ovn-controller.8.xml
> b/controller/ovn-controller.8.xml
> > index 57e7cf5dd..33281a4d6 100644
> > --- a/controller/ovn-controller.8.xml
> > +++ b/controller/ovn-controller.8.xml
> > @@ -531,6 +531,17 @@
> > 65535.
> >
> >
> > +
> > +external_ids:ovn-managed-flow-restore-wait in the
> > +Open_vSwitch table
> > +
> > +
> > +When set to true, this key indicates that
> ovn-
Re: [ovs-dev] [PATCH ovn v3] controller: Fix bfd up too early after unexpected reboot.
On 3/26/26 5:16 PM, Xavier Simonart 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, on chassis hosting ha gateways, OVN toggles flow-restore-wait:
> it 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.
>
> OVN also sets external_ids->ovn-managed-flow-restore-wait when setting
> flow-restore-wait. When set, it tells that OVN once set flow-restore-wait.
>
> "ovs-ctl restart" also uses flow-restore-wait: when called, it saves the
> flows, stops "ovs-vswitchd", sets "flow-restore-wait" to true, restarts
> "ovs-vswitchd", restores the flows and finally removes "flow-restore-wait".
> So OVS will wait either for "ovs-ctl restart" to remove "flow-restore-wait"
> or for OVN to set "flow-restore-wait" to false.
>
> Reported-at: https://issues.redhat.com/browse/FDP-3075
> Signed-off-by: Xavier Simonart
>
> ---
> -v2 : - Updated based on Mark's feedback (commit message, comments).
> - Avoid setting flow-restore-wait for computes.
> - Add external_ids->ovn-managed-flow-restore-wait.
> - Updated test: add test for compute update + nits (variable name
> changes)
> -v3 : - Fix test failing on CI (using wrong host socket)
> - Address nits from Dumitru + few more nits (related to comments).
> - Increased tolerated loss (and add comment) to avoid flakiness.
> - Rebased.
> ---
Hi Xavier,
Thanks for the v3!
> controller/bfd.c| 5 +-
> controller/bfd.h| 4 +-
> controller/ovn-controller.8.xml | 11 +
> controller/ovn-controller.c | 173 +-
> tests/multinode-macros.at | 46 +++
> tests/multinode.at | 548 ++--
> 6 files changed, 612 insertions(+), 175 deletions(-)
>
> diff --git a/controller/bfd.c b/controller/bfd.c
> index 3b0c3f6da..56bfa4936 100644
> --- a/controller/bfd.c
> +++ b/controller/bfd.c
> @@ -117,13 +117,14 @@ bfd_calculate_active_tunnels(const struct ovsrec_bridge
> *br_int,
> *
> * If 'our_chassis' is C5 then this function returns empty bfd set.
> */
> -void
> +bool
> bfd_calculate_chassis(
> const struct sbrec_chassis *our_chassis,
> const struct sbrec_ha_chassis_group_table *ha_chassis_grp_table,
> struct sset *bfd_chassis)
> {
> const struct sbrec_ha_chassis_group *ha_chassis_grp;
> +bool chassis_is_ha_gw = false;
> SBREC_HA_CHASSIS_GROUP_TABLE_FOR_EACH (ha_chassis_grp,
> ha_chassis_grp_table) {
> bool is_ha_chassis = false;
> @@ -143,6 +144,7 @@ bfd_calculate_chassis(
> sset_add(&grp_chassis, ha_ch->chassis->name);
> if (our_chassis == ha_ch->chassis) {
> is_ha_chassis = true;
> +chassis_is_ha_gw = true;
> bfd_setup_required = true;
> }
> }
> @@ -178,6 +180,7 @@ bfd_calculate_chassis(
> }
> sset_destroy(&grp_chassis);
> }
> +return chassis_is_ha_gw;
> }
>
> void
> diff --git a/controller/bfd.h b/controller/bfd.h
> index f8fece5a5..3e3384891 100644
> --- a/controller/bfd.h
> +++ b/controller/bfd.h
> @@ -16,6 +16,8 @@
> #ifndef OVN_BFD_H
> #define OVN_BFD_H 1
>
> +#include
> +
> struct hmap;
> struct ovsdb_idl;
> struct ovsdb_idl_index;
> @@ -36,7 +38,7 @@ void bfd_run(const struct ovsrec_interface_table *,
> const struct sbrec_sb_global_table *,
> const struct ovsrec_open_vswitch_table *);
>
> -void bfd_calculate_chassis(
> +bool bfd_calculate_chassis(
> const struct sbrec_chassis *,
> const struct sbrec_ha_chassis_group_table *,
> struct sset *);
> diff --git a/controller/ovn-controller.8.xml b/controller/ovn-controller.8.xml
> index 57e7cf5dd..33281a4d6 100644
> --- a/controller/ovn-controller.8.xml
> +++ b/controller/ovn-controller.8.xml
> @@ -531,6 +531,17 @@
> 65535.
>
>
> +
> +external_ids:ovn-managed-flow-restore-wait in the
> +Open_vSwitch table
> +
> +
> +When set to true, this key indicates that ovn-controller
> +has set the other_config:flow-restore-wait option.
> +The key is set when ovn-controller enables
> +flow-restore-wait and removed when it clears it.
> +
> +
>
> external_ids:ct-zone-* in the Bridge table
>
> diff --git a/controller/ovn-controller.c b/controller/ovn-contro
