Description of problem:
Currently the neutron-ovn-db-sync-util does not sync OVN LBs into the ovsdbs, if there is any inconsistency with these records we can not use the sync tool to fix these.

In 2078793 bugzilla for example and issue was hit and the only work around on the customer case(03245762) was to manually delete the records from the Octavia database. It was suggested that the sync tool may be able to be used to repair the entry but checking on a remote session this proved not to be the case, checking the code you can see why[1].

This is due to the fact that currently the sync tool only supports syncing data from the Neutron database, these LBs from ovn-octavia-provider are stored in the Octavia database

I'm opening this bug to discuss whether this is something we would like to fix, and if so how we would like to go about it.

Some suggestions were, creating a new sync tool for Octavia which would be owned by that team. Enabling some type of hook method in the neutron sync until that code from Octavia could use, or adding it to some shared library.

Please let me know your thoughts on this.

[1] https://opendev.org/openstack/networking-ovn/src/commit/eacab77be788dadc04255a4ff56d25333c159ad1/networking_ovn/ovn_db_sync.py#L88-L100

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. Delete LB record from the OVN database
2. Run the sync util
3. See that the LB is still missing from the DB

Expected results:
If a LB record is missing or inconsistent we should have some method to re-sync this with the original data from the Galera database

Steps to validate:
The steps to evaluate manually are as follow:
1 - In a octavia rhoso deploy (obviously including ovn-provider) create a LB/listener/pool/member (optionally HM or FIP attached to VIP)
2 - Once OVN LB is created go to ovn-controller pod and run (to get uuid and get a copy of the original OVN LB previously to destroy it in next step)
    

oc rsh -n openstack ovsdbserver-nb-0 ovn-nbctl --no-leader list load_balancer

3 - Once 1 is completed, go to OVN NB DB and delete the OVN LB from there
    

oc rsh -n openstack ovsdbserver-nb-0 ovn-nbctl destroy load_balancer <uuid> ----> this needs to be running over the leader on the cluster ovsdbserver-nb-[0|1|2]

4 - connect to octavia-api pod and run 

    oc rsh -n openstack octavia-api octavia-ovn-db-sync-util

5 - Once command finalized OVN LB should be again on the OVN NB DB fully operational.

    oc rsh -n openstack ovsdbserver-nb-0 ovn-nbctl --no-leader list load_balancer