On Fri, Oct 19, 2012 at 05:33:47PM -0700, Gurucharan Shetty wrote: > > > > I think one could argue for saving a copy if restoring flows fails. > > However: the most likely source of problems is "dump-flows" output > > that "add-flows" fails to accept. In such a case, I would hope that > > ovs-ofctl prints the flow that is not accepted, which would usually be > > enough to see the problem. If it does, then it would be really > > helpful to log ovs-ofctl's stdout and stderr, at least in failure > > cases. If it doesn't, then I guess we should work on that. > > > ovs-ofctl does give out an error but does not print the actual flow that > caused the error. > I will go ahead and keep the flows in between "EOF"s as you suggested.
Hmm. Maybe we should schedule some time to improve ovs-ofctl's error reporting. > > I think you could use "ovs-appctl ofproto/list" or "ovs-dpctl > > dump-dps" as a substitute for "ovs-vsctl list-br" here that does not > > require the database to be running. > > > > > > For the same reason, in the "restart" case, is it possible to change > > > > the order to stop/start ovsdb, then stop/start ovs-vswitchd? > > > > > > > Out here too, I will need the bridges before hand. Wouldn't it delay > > things > > > if I start the database first? I can get the bridges first, and then stop > > > the database. > > > > The total time isn't as important as the amount of time that > > ovs-vswitchd is not running. It's fine to stop and start the > > database, then to stop and start vswitchd. > > > > > > It's not obvious to me why saving datapaths and saving interfaces are > > > > separate steps. Can we combine these steps? > > > > > > > Are you saying, make a single function call to ovs-save? Or make 2 > > function > > > calls, but use the same script to store the results? > > > > The former. There may well be some rationale behind the two steps, I > > just didn't see it off-hand, so I was hoping you could help me out. > > > There are a couple of reasons. Saving interfaces is on all the internal > devices. > Saving datapath configuration is on all the datapaths. So the input to > ovs-save is different. > > Also, I need to restore datapath after insmodding the kernel module. OK... > The interface configuration restore needs to happen after vswitchd starts. It certainly needed to before, but that was because the interfaces didn't actually exist until ovs-vswitchd started. Now that we're recreating them ourselves with the script that save-datapaths created, we could restore it earlier. However, this seems like a good enough way to modularize, so let's leave it as you have it. Thanks, Ben. _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
