I did a little test, yes, ports on br-tun will disappear after restart openvswitch, but not flows on br-tun.
For losing ports on br-tun, I consider the root reason is here: https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/l2pop/rpc_manager/l2population_rpc.py#L231 If we only restart openvswitch, neutron ovs-agent will keep ofport cache for ports on br-tun. And that will stop neutron ovs-agent to create tunnel to remove IP, so ports on br-tun will not be re-created.
As we have methods like get_port_name_list and get_port_ofport in https://github.com/openstack/neutron/blob/master/neutron/agent/common/ovs_lib.py, so I think we can add some logic to check whether ofport is in br-tun current existing ofports.
This way is not the best way, but will cause less coding changing.
I did a little test, yes, ports on br-tun will disappear after restart openvswitch, but not flows on br-tun.
For losing ports on br-tun, I consider the root reason is here: /github. com/openstack/ neutron/ blob/master/ neutron/ plugins/ ml2/drivers/ l2pop/rpc_ manager/ l2population_ rpc.py# L231
https:/
If we only restart openvswitch, neutron ovs-agent will keep ofport cache for ports on br-tun. And that will stop neutron ovs-agent to create tunnel to remove IP, so ports on br-tun will not be re-created.
As we have methods like get_port_name_list and get_port_ofport in https:/ /github. com/openstack/ neutron/ blob/master/ neutron/ agent/common/ ovs_lib. py, so I think we can add some logic to check whether ofport is in br-tun current existing ofports.
This way is not the best way, but will cause less coding changing.