[ovs-discuss] OVS deleting flows from the datapath on exit
fbl at sysclose.org
Mon Nov 4 14:33:05 UTC 2019
On Fri, 1 Nov 2019 13:35:07 -0700
Ben Pfaff <blp at ovn.org> wrote:
> OVS currently can gracefully exit in two ways: either with or without
> deleting the datapath. But, either way, it deletes all of the flows
> from the datapath before it exits. That is due to commit e96a5c24e853
> ("upcall: Remove datapath flows when setting n-threads."), which was
> first released in OVS 2.1 back in 2014.
> This isn't usually a big deal. However, some controller folks I'm
> talking to are concerned about upgrade. If the datapath flows
> persisted after OVS exits, then existing network connections (and
> perhaps some that are "similar" to them because they match the same
> megaflows) could carry on while the upgrade was in progress.
> I am surprised that I have not heard complaints about this in the 5
> years that the behavior has been this way. Does anyone have any
> stories to report about it now that I bring it up? Contrariwise, if
> we changed OVS so that it did not delete datapath flows on exit, can
> anyone suggest what problems that might cause?
Well, I heard complains about updating OvS package causing a long
downtime in OSP environments mainly because all the flows needed to be
rebuilt at OSP side which was a slow process.
When a service is restarted, it is expected to come up with a "clean
and fresh state" and so far flows were seen as "temporary" data. In
order to provide the option to restore the flows, the following commit
was introduced to create a "reload" service:
Author: Timothy Redaelli <tredaelli at redhat.com>
Date: Fri Nov 3 21:39:17 2017 +0100
rhel: Add support for "systemctl reload openvswitch"
Now the openvswitch service could be restarted with flows persisting.
There was also an investigation to preserve the kernel datapath cache
during the reload to be less disruptive as possible. However after the
above commit I never heard about package update issues again, so we
dropped the kernel datapath persistent effort.
More information about the discuss