[ovs-dev] [PATCH 1/2] ovs-ctl.in: Ability to save flows and kernel datapath config.
blp at nicira.com
Mon Oct 22 18:15:17 UTC 2012
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
> > 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
> 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.
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.
More information about the dev