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. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev