[ovs-dev] [PATCH 2/2] ovs-ctl.in: Restore flows across force-reload-kmod.

Gurucharan Shetty shettyg at nicira.com
Tue Jan 15 23:27:44 UTC 2013


On Tue, Jan 15, 2013 at 11:46 AM, Ben Pfaff <blp at nicira.com> wrote:
>
> On Fri, Jan 11, 2013 at 03:48:41PM -0800, Gurucharan Shetty wrote:
> > If we want to upgrade from branch1.9 to master (or potential 1.10)
> > and restore flows across force-reload-kmod, we need to maintain
> > the value of ofport.
> >
> > To do this, we fetch the value of ofport before the upgrade and use
> > it to populate the column 'ofport_request' after ovsdb is upgraded.
> > We need to do this before vswitchd is restarted as vswitchd
> > needs the ofport_request column populated before it starts.
> >
> > Issue #13556
> > Signed-off-by: Gurucharan Shetty <gshetty at nicira.com>
>
> We seem to do this on every upgrade, but in fact it's only useful for
> upgrades from 1.9 to 1.10 or later, right?

Sorry, my commit message does not give the correct picture. It should have read

"If we want to upgrade from a previous branch to master..."

The current patch should be able to handle flow restore when there
is an upgrade from any previous branch to current master(1.10).

But we won't need to save ofports while upgrading from 1.10 to a
future branch (because ofport
becomes persistent in 1.10). So we eventually can remove it. Its
presence does not hurt,
but it will be unnecessary.

Removing "save ofports" in a future branch will not restore flows for
a upgrade from pre-1.10 branch(ex: 1.9) to that future
branch.  To avoid a situation like that I can do something like this:

save_ofports ()
{
#VERSION will hold major number and minor number without dots. Ex: ab
for a.b.c.d
VERSION=`ovs-appctl version | sed -n '/ovs-vswitchd/s/[^0-9]*//p' |
sed 's/\([^\.]*\)\.\([^\.]*\).*/\1\2/'`
if [ "${VERSION}" -gt 19 ]; then
   return
fi
....
....
....

}

I am not sure whether it is a overkill.

Thanks,
Guru


>
>  It would be better to do
> this only when it is useful or at least note in the script why we are
> doing it so we can remember to remove it later on.
>
> Otherwise it seems reasonable.  Thank you!



More information about the dev mailing list