Hi Russell, Nice writeup of the issues and potential solutions. We have been thinking along the same lines.
Cheers, Dan On Mon, Mar 7, 2016 at 11:29 PM, Russell Bryant <russ...@ovn.org> wrote: > On Sun, Mar 6, 2016 at 11:40 PM, Dan Mihai Dumitriu <dm...@cornell.edu> > wrote: > >> I'd argue for the approach of keeping the OVSDB protocol in place, >> because the SB schema is already there, well understood, and making the >> central DB a fault tolerant cluster would have little or no impact on the >> ovs-controller implementation. It would also allow the current single OVSDB >> to continue to function while the cluster is developed. >> >> That said, if the current OVSDB doesn't have an ACL model, I have some >> security and robustness concerns, once it's run at scale. Has it been >> considered to add an ACL model to OVSDB? >> > > I've put some thought into the security concerns of the southbound > database. I wrote a bit about this in the ovn/TODO file. See "limiting > the impact of a compromised chassis". > > https://github.com/openvswitch/ovs/blob/master/ovn/TODO#L128 > > Since writing that, I've come to think that as a first step, making > ovn-controller (at least optionally) only have read-only access to the > southbound database would be a good step. This would require: > > - Instead of having ovn-controller create the Chassis and Encap rows for > itself, make that an administrative task when bring a new chassis online. > This can be done with the ovn-sbctl utility. It's data that is set once > and very rarely changed. > > - Move the job of assigning port bindings. Right now ovn-controller sees > ports appear locally and automatically matches them up with OVN logical > ports and updates the port bindings. This is quite convenient, but we > could optionally force an external entity to define the port bindings > instead. In the case of OpenStack, the Neutron plugin could do this. In > fact, Neutron already expects to be in charge of port-host bindings, and we > just ignore that for OVN right now. > > If we take that route, this doesn't seem too hard to do. > > -- > Russell Bryant > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
