I see a couple of distinct discussions occurring on this thread, maybe it’s time to deal with them independently.
The Security/ACL aspect of the protocol - Is there some reason why existing SSL authentication and encryption mechanisms is not adequate enough for security. I am not opposed to building logic into the protocol that “restricts” access to tables, but does that solve the security aspect of the problem completely? Whether to move the SB DB to an Open Source database that support monitoring and notification of changes - Here the question is which one? We have seen RabbitMQ (used as a notification mechanism) having trouble keeping up with NOVA and Neutron (in non-OVN use case) for OpenStack once the number of compute nodes exceed the number 1000 - there is a debate about whether it’s the consumers using RabbitMQ correctly that is causing this. I only bring up RabbitMQ as it’s a pub/sub scheme I am familiar with. From my point of view, the choice of the notification mechanism matters more than the distributed DB that is used. -- Amitabha > On Mar 7, 2016, at 6:49 AM, Russell Bryant <russ...@ovn.org> wrote: > > On Mon, Mar 7, 2016 at 9:47 AM, Dan Mihai Dumitriu <dm...@cornell.edu> > wrote: > >> 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. >> > > Good points. Thanks for sharing. > > -- > Russell Bryant > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
