I should have also noted who was already looking at each of these items ...
On Thu, Oct 13, 2016 at 10:02 AM, Numan Siddique <nusid...@redhat.com> 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. >> > Lance has an RFC patch posted for this. > >> 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. >> > Numan has a patch for this, not yet posted as I wanted to post 2-4 together. > 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. >> > I'm working on this. > 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. >> > Babu has a patch for this. > >> > 5) Remove support from ovn-controller updating the 'Chassis.hv_cfg' > column and handle the side effect in "--wait=hv" in ovn-nbctl. > Ah yes, I missed this. My initial thought is that since this is primarily useful for testing, we could accept this as a limitation of the feature and it just wouldn't work if you didn't expose write access to ovn-controller. A huge downside to this is that if we're not enforcing read-only access in our test suite, we're more likely to have regressions. Any other ideas? -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
