On Tue, Apr 08, 2014 at 11:10:01AM -0700, Gurucharan Shetty wrote: > On Mon, Mar 31, 2014 at 1:19 PM, Ben Pfaff <b...@nicira.com> wrote: > > On Tue, Mar 25, 2014 at 02:50:17PM -0300, Flavio Leitner wrote: > >> It should be an administrator task to bring up devices as they > >> are configured properly. > >> > >> Currently, Fedora is deleting the bridges when the interface is > >> brought down. Therefore, there is no bridge on the next boot and > >> the initscripts can apply the networking configuration properly > >> for a new bridge. > >> > >> However, if the system didn't execute ifdown for some reason, the > >> bridge is left in the ovsdb and since internal ports are brought > >> up by default, there is no way for initscripts to known if the > >> adminitrator has configured it or not already. > >> > >> This patch partially reverts the commit > >> bef071a5fdf8e2dd87677b04b3cf7a8f5094edcb > >> > >> Signed-off-by: Flavio Leitner <f...@redhat.com> > > > > I think you're right, that this is correct, but let's put the NEWS > > item at the top and give a little more explanation, something like > > this: > > > > - Internal ports are no longer brought up by default, because it should > > be > > an administrator task to bring up devices as they are configured > > properly. > > > > This is almost certain to break some people's setups, but I guess it's > > better than what we do now. > In most of the setups using Open vSwitch on hypervisors, we have a > integration bridge(br-int) with VM virtual interfaces attached to it > through a third utility (e.g., libvirt). > So far, adding a bridge to a ifcfg-* script or interfaces (on debian) > script was optional. Assuming there is a kernel crash or a reboot, > br-int would be automatically be UP and VMs would get started > automatically and traffic would flow after an outage. Now, that won't > be the case anymore. One is forced to add these bridges to some sort > of startup network configuration scripts. Assuming, we do ask users to > add some way to auto-start their integration bridge, then these > bridges are deleted and re-created. So any ports added will have to be > added back.
That sounds expected to me. If you want a stable configuration, then you should put the networking setup into the startup network configuration scripts. > Also, if someone programmatically creates bridges using OVSDB, he is > now forced to add those bridges to some startup script. I don't think > it is feasible. Good point, but how you handle the networking configuration in this case? For instance, when the new bridge needs an IP address. > I feel that a default UP has less negative consequences than a default down. Currently there is no clear boundary between ovsdb and system's admin tools, so it's hard to tell which one is correct. I am not happy with Fedora's script deleting the bridges at shutdown because the startup scripts can't restore all the possible configuration ovsdb offers. However, somehow we need to know when the device should or should not be restored/configured at the initialization and by that I mean, bring the device to live with the proper networking configuration. Today if the bridge doesn't exist, it's created and configured. If the bridge exists, but it's down, then it is configured. Otherwise it's assumed that the bridge is properly running. > Thanks, > Guru > > > > > Please give a title when referring to a commit in a log message, e.g.: > > > > This patch partially reverts the commit > > bef071a5fdf8e2dd87677b04b3cf7a8f5094edcb (bridge: Always "up" internal > > devices.). > > > > Finally, I would have just fixed all of the above and pushed it, > > except that it also breaks half a dozen tests in the testsuite. > > Please fix those and submit a v3. > > > > Thanks, > > > > Ben. > > _______________________________________________ > > dev mailing list > > dev@openvswitch.org > > http://openvswitch.org/mailman/listinfo/dev > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
