On Thu, Mar 17, 2016 at 09:54:14AM -0400, Aaron Conole wrote:
> Ben Pfaff <b...@ovn.org> writes:
> > On Mon, Feb 29, 2016 at 03:40:56PM -0500, Aaron Conole wrote:
> >> Currently, ``ovs-ctl start'' will attempt to start both the DB and
> >> vswitchd. This is quite convenient when the database already has all of
> >> the configuration values required, and when using a single services file
> >> for systemd integration. The same goes for the ``ovs-ctl stop'' command.
> >>
> >> However, there are some cases which are not easily covered. The case
> >> where we want to set values in the database prior to starting the
> >> forwarding path, as well as the case of supporting multiple service
> >> files, one per daemon (which is how systemd expects services to look).
> >>
> >> Signed-off-by: Aaron Conole <acon...@redhat.com>
> >> ---
> >> v1: Limited testing (just some quick start/stop testing). The documentation
> >> updates are rather quick.
> >> See http://openvswitch.org/pipermail/dev/2016-February/066502.html for
> >> more information.
> >
> > This seems pretty reasonable. I have a few comments.
> >
> > We have some precedent around options for ovsdb-server and ovs-vswitchd:
> > so far, we've started options for them with their program names, as in
> > --ovsdb-server-wrapper and --ovsdb-server-priority. I think that it
> > would be reasonable to continue this; --control-forwarding and
> > --control-ovsdb is a bit of a departure. So I'd consider just naming
> > these as --ovsdb-server and --ovs-vswitchd, so that to disable them one
> > uses --no-ovsdb-server or --no-ovs-vswitchd.
>
> Okay; I'll incorporate this.
>
> > Second, these options make sense for "start" and "stop". For some of
> > the other commands it's necessary to be more nuanced. So, for example,
> > for "restart", we would not want to call save_flows_if_required and
> > restore_flows if we're not restarting ovs-vswitchd. And I'm not sure
> > that it makes any sense to run "force-reload-kmod" if one is not
> > restarting ovs-vswitchd.
>
> Agreed.
>
> > Actually I think I see some opportunity for simplification now in
> > ovs-ctl, because there is special-case code there for upgrading from
> > obsolete versions (before OVS 1.10). I think I'll send out a patch to
> > remove those special cases, which ought to make it easier to think
> > through the cases here.
>
> Sounds good. I'll wait for your patches and respin this.
They're in now, see the following:
commit 87530bc1c1c1046c9bcff454e96df15fbb31d1cf
Author: Ben Pfaff <b...@ovn.org>
Date: Wed Mar 16 16:45:29 2016 -0700
ovs-ctl: Remove code for upgrading from Open vSwitch 1.6 and earlier.
OVS 1.7 was released in July 2012, so by the time current OVS is released,
it will be almost four years old. I think that this is long enough to
remove special upgrade code.
It's almost impossible to do this upgrade in any case since there is
no overlap in the base kernel versions supported by the out of tree
modules in the two versions (the only possibility is running the new
version of OVS on the upstream module from Linux 3.3).
Signed-off-by: Ben Pfaff <b...@ovn.org>
Acked-by: Jesse Gross <je...@kernel.org>
commit c416eaf8c247225f0ebeb22b6ca5c473e96a53d2
Author: Ben Pfaff <b...@ovn.org>
Date: Wed Mar 16 20:10:40 2016 -0700
ovs-ctl: Remove code for upgrading from Open vSwitch 1.9 and earlier.
OVS 1.10 was released in May 2013, so by the time current OVS is released,
it will be about three years old. I think that this is long enough to
remove special upgrade code from the startup scripts.
Signed-off-by: Ben Pfaff <b...@ovn.org>
Acked-by: Jesse Gross <je...@kernel.org>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
