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