Ben Pfaff <b...@ovn.org> writes:
> On Mon, May 02, 2016 at 01:08:53PM -0400, Aaron Conole wrote:
>> The ovs-ctl script was changed recently to have per-service start/stop
>> control. However, when that change was made the add_managers() call was
>> overlooked. This results in calls to `ovs-ctl --no-ovs-vswitchd start`
>> telling the ovsdb-server to connect to the remote controllers.
>>
>> This commit disables the effect of the add_managers call if the
>> `--no-ovs-vswitchd` argument is given.
>>
>> Fixes: 7fc28c50c012 ("ovs-ctl: Allow selective start for db and switch")
>> Signed-off-by: Aaron Conole <acon...@redhat.com>
>
> I think this means that if we first start ovs-vswitchd, then separately
> start ovsdb-server in a later call to ovs-ctl, nothing will add the
> remote managers. That's because, when we start ovs-vswitchd,
> ovsdb-server isn't running, so we can't enable anything, and then later
> when we start ovsdb-server, we don't add the remotes because we're not
> starting ovs-vswitchd.
Hrrm, I didn't consider that it was common to start vswitchd before the
database.
> So, it might be better to condition this on $OVSDB_SERVER. Then we'll
> at least get the above case right, and the behavior in the common case
> where we start both at once will be unchanged. There will be a bit more
> churn from managers' perspective in the uncommon case where we start in
> an odd order, but at least we'll connect to them.
We really only want this to happen when both come alive; given there are
tests for both daemons being up, I can try to make it a bit more
intelligent and solve either order, with the connect signal only coming
when the second daemon starts.
I'll cook up a v2 sometime this week, and see if it will pass muster.
Thanks for the perspective, Ben!
-Aaron
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
