> > 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.
> > > > The logging seems more elaborate than I would expect in > > > restore_datapath and in stop_forwarding. These functions now log the > > > commands that they are running and their success or failure. Although > > > that's reasonable to do, if we are going to do it for these particular > > > actions then I'd think we'd want to do that for pretty much every > > > action. (If you think that's a good idea then I'd be OK with it.) > > > > I looked at the model we have for "Restoring interface configuration" > > action and I was confused about what to do for the 2 new additions > > that I am making. I will get rid of the logging for the 2 new additions. > > Should I keep the old logging intact? > > Oh gosh, I didn't realize there was precedent for this. Hmm. Well, > never mind, let's do it this way. (But watch out for logging the > whole file, for restoring the flow table, since the flow table can be > many thousands of lines long, or even longer. I think we'd be better > off making sure that we can log the actual error, as discussed above, > instead of logging the whole thing.) > > It'd be nice if you could factor out a shell function for this. > Okay > > > > In force_reload_kmod, this change moves stopping ovs-vswitchd from > > > after starting and stopping the database to before starting and > > > stopping the database. That will extend the period of time when new > > > flows cannot be set up. Is it really necessary to do it? > > > > > In stop_forwarding, I use 'ovs-vsctl list-br' command which needs the > > database. According to the comment in the code, starting a large database > > may take time. So, I wanted to save the flows first and then stop the > > database. > > The time that we're most worried about is the time during which > ovs-vswitchd is not running. stop_forwarding kills ovs-vswitchd, so > doing the slow part (restarting ovsdb-server) after we kill > ovs-vswitchd and before we restart it is not a good idea. > Got it. > > 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. The interface configuration restore needs to happen after vswitchd starts. > > Thanks, > > Ben. >
_______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
