I would argue for a server-side OVSDB to other backend proxy. I would also argue against a client side (in ovn-controller) abstraction of the other-db - one reason for this is related to the security/safety argument, in the sense that other-db may not have any ACL mechanism, or any way to limit what the client can do, and thus would be susceptible to a compromised chassis. If OVN has its own RPC mechanism between the chassis (ovn-controller) and the control cluster, the security issues can be controlled more precisely, considering the particular requirements of this system. I think there are also advantages for doing upgrades, and just generally for decoupling the ovn-controller implementation from the db backend.
On Mon, Mar 7, 2016 at 11:34 PM, Russell Bryant <russ...@ovn.org> wrote: > On Mon, Mar 7, 2016 at 9:29 AM, 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. >>> >> > Do you also mean keep ovsdb-server, or did you mean writing a server-side > OVSDB-to-other-db proxy? > > I was thinking that if we wanted to add support for another db, doing it > with a client side abstraction would be better instead of adding our own > custom server-side component. > > -- > Russell Bryant > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev