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

Thadeu Lima de Souza Cascardo cascardo at redhat.com
Thu Aug 27 19:10:57 UTC 2015

On Thu, Aug 27, 2015 at 11:28:21AM -0700, Ben Pfaff wrote:
> 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.

That's reasonable when all configurations can be persisted by other methods. I
believe that are scenarios where the system is capable of persisting some
configurations but not others. In those cases, it's preferable to have an option
like --delete-transient-ports then the alternatives: deleting all bridges or
have those undesired failures.

I will send a V2.

Gurucharan, I think that solves your concern about restoring flows. Is that OK
for you?


More information about the dev mailing list