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 <casca...@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? Thanks. Cascardo. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
