[ovs-dev] ovn: Improving southbound database security

Ben Pfaff blp at ovn.org
Thu Oct 20 17:47:16 UTC 2016


On Thu, Oct 13, 2016 at 07:32:53PM +0530, Numan Siddique wrote:
> We may have to add one more item in the task breakdown list. Please see
> below
> 
> 
> On Wed, Oct 12, 2016 at 11:21 PM, Russell Bryant <russell at ovn.org> wrote:
> 
> > Hello, I'm back to looking at southbound database security concerns in
> > OVN.  A previous thread discussing approaches was here:
> >
> >     http://openvswitch.org/pipermail/dev/2016-August/078106.html
> >
> > I'm now working with a few others on implementing a proposed solution.
> > The overview is that we'd like to make ovn-controller a read-only client of
> > the southbound database.
> >
> > The task breakdown is:
> >
> > 1) Add support to ovsdb-server for read-only remotes.  The port reachable
> > by ovn-controller would only accept read-only connections.
> >
> > 2) Remove support from ovn-controller for automatically creating chassis
> > and encap records.  Document this as an administrative step for adding a
> > new chassis to the system, instead.
> >
> > 3) Remove support from ovn-controller for setting the chassis column of
> > Port_Binding records.  Instead, have this handled by ovn-northd based on
> > binding instructions given in the northbound database.
> >
> > As a nice side effect, this helps solve one of the difficulties with live
> > migration (two chassis fighting to own a port while the migration is in
> > progress).  Instead, we would update OVN when we know the migration is
> > complete.
> >
> > I was originally thinking we may need an upgrade utility to help existing
> > environments, but I think ovn-northd can handle this automatically.
> >
> > For the northbound database, I was thinking of adding a new option for
> > logical ports called "chassis" with a value of the hostname of the chassis
> > the port should be bound to.
> >
> > 4) Remove use of MAC_bindings table from ovn-controller.  Replace it with
> > a local cache, instead.  I'm proposing just keeping it in memory in
> > ovn-controller, but we could also make use of the openvswitch db.
> >
> > One detail I haven't fully thought through: what should happen to the
> > MAC_Bindings table?  Dropping the table seems not backwards compatible and
> > would break a rolling upgrade scenario.  Should we leave it as unused for
> > one release, and then remove it in the next release?  More generally, I
> > think we need to document our upgrade strategy and related rules for
> > database schema changes.
> >
> >
> ​5) Remove support from ovn-controller updating the 'Chassis.hv_cfg'
> column​ and handle the side effect in "--wait=hv" in ovn-nbctl.

The ability to wait for hypervisors to catch up is pretty valuable.  I'm
not super happy about losing it.



More information about the dev mailing list