On 1/28/22 18:04, Dumitru Ceara wrote:
> On 1/24/22 12:30, Vladislav Odintsov wrote:
>> After commit [0] the mandatory vtep chassis's option 'is-vtep' has appeared.
>> The upgrade scenario for ovn-controller-vtep was not supported:
>> 'is-vtep' option was set only on vtep chassis creation. If chassis was
>> created prior to a new codebase, it was left intact and HW VTEP connectivity
>> was broken.
>> This commit fixes such scenario and now 'is-vtep' is set for vtep chassis
>> other_config if was not set yet.
>>
>> 0:
>> https://github.com/ovn-org/ovn/commit/1c360bbd911cab9fadd6df8cd528d992ffa7a998
>>
>> Fixes: 1c360bbd911cab9fadd6df8cd528d992ffa7a998 (Fix basic multicast flows
>> for vxlan (non-vtep) tunnels)
Another tiny nit, this should be:
Fixes: 1c360bbd911c ("Fix basic multicast flows for vxlan (non-vtep) tunnels")
Generated with:
git log -1 --pretty=format:"Fixes: %h (\"%s\")" --abbrev=12
1c360bbd911cab9fadd6df8cd528d992ffa7a998
>> Signed-off-by: Vladislav Odintsov <odiv...@gmail.com>
>> ---
>
> Looks good to me, thanks!
>
> Acked-by: Dumitru Ceara <dce...@redhat.com>
>
> One nit though: it would be nice to have a test for this, e.g, list the
> chassis check that is-vtep is set, remove is-vtep, wait until
> ovn-controller-vtep readds it. What do you think?
>
> Regards,
> Dumitru
>
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
