[ovs-dev] [RFC] ovs-ctl: Allow selective start for db and switch
Aaron Conole
aconole at redhat.com
Thu Mar 17 13:54:14 UTC 2016
Ben Pfaff <blp at 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 <aconole at 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.
Thanks so much for the review, Ben!
-Aaron
More information about the dev
mailing list