[ovs-dev] [PATCH 1/2] ovs-ctl.in: Ability to save flows and kernel datapath config.

Gurucharan Shetty gshetty at nicira.com
Sat Oct 20 00:33:47 UTC 2012


>
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20121019/791c8df0/attachment-0003.html>


More information about the dev mailing list