[ovs-dev] [PATCH 2/2] ovs-vsctl: add command to delete transient ports from bridge

Ben Pfaff blp at nicira.com
Thu Aug 27 18:28:21 UTC 2015

On Thu, Aug 27, 2015 at 12:07:32PM -0300, Thadeu Lima de Souza Cascardo wrote:
> When using virtualization, new ports are created and removed all the time. These
> ports do not persist after a system reboot, for example. They may be created
> again by the virtualization manager, but that will happen after the vswitch is
> already running, and the virtualization manager will add them again to the
> bridge.
> If a reboot happens without properly deleting such ports, all kinds of errors
> will happen. The absence of the ports will be logged as errors, and adding those
> ports again to the database will fail.
> This patch introduces the notion of transient ports. Ports may be added as
> transient, as a boolean in other_config smap. When openvswitch is restarted by
> using ovs-ctl, all transient ports will be removed. If the system administrator
> wants to remove all transient ports from a bridge, a new ovs-vsctl command,
> del-transient-ports may be used.
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo at redhat.com>

I would think that reboot should be distinguished from restart within a
boot.  Restart can happen for a number of reasons, e.g. to upgrade OVS
userspace, to upgrade the OVS kernel module, to troubleshoot suspected
bugs.  In most of these cases one would not want to delete all of these
"transient" ports.

Therefore I'd consider implementing this feature as an option like the
existing --delete-bridges option, something like
--delete-transient-ports.  The system would supply the option only on
the first start following boot.

Actually, that makes me wonder whether --delete-bridges is the right
solution.  It makes a lot of sense to start fresh from an empty set of
bridges at boot time because it provides a "clean slate" at each boot on
which to reproducibly build up a set of bridges and ports.  It worked
well on XenServer when we originally introduced it and I wonder whether
it's the right model everywhere.

More information about the dev mailing list