On Thu, Apr 13, 2023 at 9:33 AM Dumitru Ceara <[email protected]> wrote:
> 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. > Just to add some extra input in here. As Dumitru mentioned, it is not just a scaling issue, but that accessing the SB has its own problems as things can change there any time (it has already happened) breaking the logic on the CMS about how to react to those changes. If we don't have the information at the NB, that means we need 2 connections, one for the NB (to be as safe as possible from the SB changes), and one for the SB to get the chassis information. Also, note there is already chassis information on the logical_switch_ports at the NB DB, so adding that for the cr-lrps should not be that different. Adding the active chassis to the HA_Chassis_group also sounds good > > 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 > -- LUIS TOMÁS BOLÍVAR Principal Software Engineer Red Hat Madrid, Spain [email protected] _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
