[ovs-dev] weekly OVN report

Dan Mihai Dumitriu dmd17 at cornell.edu
Mon Mar 7 14:47:52 UTC 2016


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 <russell at ovn.org> wrote:

> On Mon, Mar 7, 2016 at 9:29 AM, Russell Bryant <russell at ovn.org> wrote:
>
>> On Sun, Mar 6, 2016 at 11:40 PM, Dan Mihai Dumitriu <dmd17 at 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
>



More information about the dev mailing list