Hello, I'm back to looking at southbound database security concerns in
OVN.  A previous thread discussing approaches was here:


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

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.

Russell Bryant
dev mailing list

Reply via email to