On 4/12/23 23:07, Han Zhou wrote: > On Wed, Apr 12, 2023 at 8:01 AM <[email protected]> wrote: >> >> From: Lucas Alvares Gomes <[email protected]> >> >> In order for the CMS to know which Chassis a distributed gateway port >> is bond to, this patch updates the ovn-northd daemon to populate the >> Logical_Router_Port table with that information. >> >> To avoid changing the database schema, ovn-northd is setting a new key >> called "hosting-chassis" in the options column from the LRP table. This >> key value points to the name of the Chassis that is currently hosting >> the distributed port. >> >> Reported-at: https://bugzilla.redhat.com/show_bug.cgi?id=2107515 >> Signed-off-by: Lucas Alvares Gomes <[email protected]>
Hi, Lucas, Han, > > Thanks Lucas for the patch. However, in my opinion the chassis binding > information belongs to SB and should stay there, otherwise we would make it > consistent for LSPs and update the chassis information for them, too, which > I think is not good in terms of clarity and extra control plane load. We'd > better keep the separation between NB and SB clear and avoid propagating > data between them back-and-forth. > I partially agree with this but it also feels wrong that the CMS accesses the SB directly. In an ideal world (and I know that's not the case today for neutron or ovn-k8s) the CMS should not care about what's in the SB; that is internal OVN data. I suggest a different approach if we want to go ahead and propagate such information to the NB: can't we store the "active chassis" information per Gateway_chassis/HA_Chassis_group instead? That's O(number-of-chassis) records that we need to update on chassis failover. We might even skip this for Gateway_chassis as I understand that this is the "old" way of configuring things (*). (*) Should we deprecate Gateway_chassis? > For the problem mentioned in the bugzilla, it seems to me already a scale > challenge that something other than ovn-controller is connecting to OVN SB > from every node (if I understand correctly). Moving all these connections > from SB to NB may just make it much worse, because NB DB is usually more > heavily/frequently updated by the CMS. (For small scale, this may not > matter, even if the agent connects to both NB and SB.) > An alternative to address the scale issue without changing OVN could be to use a dedicated SB relay to which all external (non-OVN) agents that need access to SB information can connect. Would that help? Regards, Dumitru _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
