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

Reply via email to