On 11/16/20 12:02 PM, Numan Siddique wrote:
> On Thu, Nov 12, 2020 at 9:25 PM Dumitru Ceara <[email protected]> wrote:
>>
>> The NB.NB_Global.nb_cfg value gets propagated to
>> Chassis_Private.nb_cfg (and then to NB.NB_Global.hv_cfg) as soon as
>> ovn-controller has finished installing OVS flows corresponding to
>> the NB DB state.
>>
>> However, if the CMS runs monitoring applications on the chassis itself,
>> in order to detect that the NB changes have been applied, it has to
>> connect to the NB/SB database.  In a scaled deployment this additional
>> connection might induce performance issues.
>>
>> In order to avoid that we now (also) propagate nb_cfg to the local OVS
>> DB, in table Open_vSwitch, as external_id "ovn-nb-cfg".
>>
>> Signed-off-by: Dumitru Ceara <[email protected]>
> 
> Hi Dumitru,

Hi Numan,

> 
> Thanks for the patch. Overall the patch LGTM. I have a couple of comments.

Thanks for the review.

> 
> 1. I think it  needs to be documented that the ovn-controller writes
> 'ovn-nb-cfg' to the local ovsdb.
> 2. I think it's better if the ovn-controller writes the ovn-nb-cfg to
> the integration bridge's external_ids column.
>    We already have Ihar's multiple ovn-controller support patch for
> review and it would conflict for this usecase.

Ack, good points, I'll address them in v2.

Thanks,
Dumitru

_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to