On Tue, Feb 9, 2016 at 12:18 PM, Russell Bryant <[email protected]> wrote:
> On 02/09/2016 01:12 PM, Kyle Mestery wrote:
>> On Tue, Feb 9, 2016 at 5:24 AM, Michael <[email protected]> 
>> wrote:
>>> Options for running ovsdb separately is done and also described in the help 
>>> file.
>>>
>>> NEWS file is updated.
>>>
>>> I just have to rise a few points:
>>>
>>> - the way thing are running with start/stop daemon from ova-lib require
>>> the daemon to have a pidfile named daemon.pid and this is impossible
>>> to use in our case because we will end up having conflict between
>>> nb and sb db because they both will appear ad ovsdb-server.
>>>
>> I think that needs to be refactored to accept a pid file name so we
>> can have it generate separate pidfiles for the different DBs.
>>
>>> - the way SSL is handles in ovs-ctl make usage of
>>> db:Open_vSwitch,SSL,private_key and I suppose we don’t have this vars
>>> using ovsdb-server without cons.db (please correct me if I’m wrong)
>>>
>> I think fundamentally we need the starting of the NB and SB DBs in
>> ovn-ctl to be done by calling start_ovsdb() from ovs-ctl. See comments
>> below.
>
> That was my suggestion, yes, but the point about about the SSL options
> is a good one.  Those are only relevant if the db is the Open_vSwitch db.
>
We could factor those out if the DB is not conf.db easily. My only
concern is duplicating code which essentially is starting ovsdb-server
with different DBs. Keeping it in one place seems reasonable to me.

> Reading start_ovsdb() in ovs-ctl again, at this point there really isn't
> much more to share so I suppose I retract the suggestion.
>
> One thing ovs-ctl is doing that we don't do in ovn-ctl is check to see
> if daemons are already running.  That'd be a helpful enhancement, but is
> not related to this patch.
>
We'd get this for free if we just used a single set of functions to
operate with ovsdb-server. ;)

> --
> Russell Bryant
_______________________________________________
dev mailing list
[email protected]
http://openvswitch.org/mailman/listinfo/dev

Reply via email to