Then UUID of the "Chassis" register is the OVS "Openvswitch.external_ids:system-id" stored value. This value is created and stored in the filesystem [1].
The "ovn-controller" process uses this OVS system-id when creating the "Chassis" register. If this system-id is changed (for example during a host upgrade), the "ovn-controller" will create a new "Chassis" register once restarted.
If by any circumstance, during this upgrade process (for example), the system-id is changed but the old "Chassis" register is not deleted from the OVN DB database by "ovn-controller" (the process is does not stop gracefully), Neutron will find two "Chassis" registers (and the corresponding "Chassis_Private") in the OVN SB database, both associated to the same host.
The question this bug is proposing is:
* Should Neutron handle this situation?
* If yes, should Neutron perform a proactive OVN SB health action?
* Should Neutron only inform to the user? (some users don't check the logs by default).
[1]https://docs.openvswitch.org/en/latest/ref/ovs-ctl.8/
Related bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2181436
Maybe we could process 'delete_agent' for the old agent if there is an new duplicate record when agent health check.
And there are any fileds like 'agent_type' or 'host' to ensure the agent is duplicate.