[ovs-dev] [PATCH v2 ovn] ovn-controller-vtep: Fix MMR create/update
odivlad at gmail.com
Thu Jun 10 21:28:47 UTC 2021
Oh, I didn’t think about this case. I’ll address this too.
A small question.
After patch would be accepted I’d like to send backport bugfix patch down to
supported branches. Is it better to use old-style AT_CHECK in tests to cleanly
apply this patch to branches without `check` support? Or in master branch I
should only use new-style and then rewrite it while backporting?
> On 10 Jun 2021, at 21:18, Dumitru Ceara <dceara at redhat.com> wrote:
> On 6/10/21 7:57 PM, Vladislav Odintsov wrote:
>>>> @@ -231,13 +239,19 @@ vtep_lswitch_run(struct shash *vtep_pbs, struct sset *vtep_pswitches,
>>>> VLOG_DBG("set vtep logical switch (%s) tunnel key from "
>>>> "(%"PRId64") to (%"PRId64")", vtep_ls->name,
>>>> vtep_ls->tunnel_key, tnl_key);
>>>> + vteprec_logical_switch_set_tunnel_key(vtep_ls, &tnl_key, 1);
>>>> - vteprec_logical_switch_set_tunnel_key(vtep_ls, &tnl_key, 1);
>>> This seems incorrect to me. If the tunnel_key column is cleared
>>> externally, with your change, we won't be resetting it.
>> There is a check if (vtep_ls->tunnel_key != port_binding_rec->datapath->tunnel_key).
>> So if it differs for some reason, vtep-controller will rewrite it. I’ve additionally checked this:
>> Set via vtep-ctl set logical-switch <uuid> tunnel_key=<another id>, then checked a value
>> (It returned to previous one) and in debug log there was:
>> 2021-06-10T17:39:11Z|00131|vtep|DBG|set vtep logical switch (subnet-789C6560) tunnel key from (11) to (10)
>> Maybe I didn’t get the idea of incorrect behaviour?
> If you run "vtep-ctl clear logical-switch <uuid> tunnel_key" with your
> change then the tunnel_key will not be reset by ovn-controller-vtep.
> dev mailing list
> dev at openvswitch.org
More information about the dev