Open Stack

On 03/26/2015 08:22 PM, Salvatore Orlando wrote:
>     To set this up outside of ovs-sandbox, you need to first create the OVN
>     northbound database:
> 
>       $ ovsdb-tool create ovnnb.db ovs-git-tree/ovn/ovn-nb.ovsschema
> 
>     Then you need to tell ovsdb-server to use it.  By default ovsdb-server
>     will only serve up conf.db.  It can take a list of dbs as positional
>     arguments, though.  You can see that's what the ovs-sandbox script
>     is doing.
> 
> Do you reckon this steps should be performed by devstack (or to be more
> precise the neutron-ovn devstack plugin that we should develop) or shall
> we assume OVN is already configured? For me both ways work. However some
> developers (like Russell I guess) will be working both on OVN and the
> neutron plugin, so maybe I'm not sure having devstack doing the OVN
> setup might be helpful for them; on the other hand this might come
> somewhat handy for setting up CI jobs. 

I think automating in devstack makes sense.  Right now I would want it
to feel like the OpenStack components in devstack.  I want an ovs git
tree that I can hack on along side my OpenStack git trees and have
everything started up using the current state of the code.  Automating
that should serve both the dev and test cases.  I'm sure the automation
will evolve over time when it's eventually packaged and so forth.  For
now it's going to be a fast moving target straight from git.

>  
> 
>     So, you can either change the command used to start ovsdb-server on your
>     system, or start up another instance of it with its own unix socket and
>     tcp port.
> 
>     There was also a question on IRC about the format of the database option
>     for the ML2 driver.  The value is passed directly to ovn-nbctl.  The
>     format is the same as is used for ovs-vsctl (and probably others).
> 
> 
> In the ovs-dev mailing list you said (correctly imo) that openstack
> should not use nbctl but rather talk directly through ovsdb with the OVN
> controller.
> It seems here you're stating the ML2 driver will pass down the database
> connection info to nbctl.
> I don't know if that's your intention, but I would rather avoid having
> another plugin that uses command line for everything.This would save us
> the pain of having to scrape through command output, and more
> importantly will avoid the overhead associated with rootwrap (daemonized
> or not).

I absolutely agree.  The current use of the utility is just a "make it
work ASAP" approach for POC purposes.  The real goal is to use ovsdb
directly.  I've been talking to Terry about using his work in Neutron
here, as well.  However, I don't want to block on that part for getting
things up and running in a first iteration.

-- 
Russell Bryant