On 4/13/23 21:42, Han Zhou wrote: > On Thu, Apr 13, 2023 at 10:01 AM Dumitru Ceara <dce...@redhat.com> wrote: >> >> On 4/13/23 18:26, Han Zhou wrote: >>>>>> >>>>>> 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 (*). >>>>>> >>> What do you mean by O(number-of-chassis) here? If a chassis fails over, > we >>> should update for > O(number-of-ports-failed-over-from-the-failure-chasssis), >>> right? >>> >> >> Is there ever a reason to have more than "number-of-chassis" >> Gateway_chassis or HA_Chassis_group records? I thought not. So, if we >> move the status per Gateway_chassis/HA_Chassis we need to update a >> smaller number of records than if we track the status per LRP. >> > For each LRP, there will be a HA chassis group, and in each group there > will be N chassis. Assume there are X LRPs residing on a specific chassis, > then if the chassis fails, the X LRPs' active chassis needs to be updated, > or equivalently, X HA chassis groups need to be updated. It may be possible > that some LRPs share the same HA chassis group, but I don't know any real > use case that use it that way, because that would end up with all LRPs > active on the same chassis (because they follow the same priority in the > same HA chassis group) and would not provide a good load sharing. >
You're right, I was stuck in the ovn-k8s case where we have one LRP per chassis. Sorry for the noise. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev