On Tue, Mar 8, 2016 at 3:15 AM, Amitabha Biswas <azbis...@gmail.com> wrote:
> 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? > > I would expect to use TLS in combination with some sort of access control. We would use TLS to secure the transport along with authentication if needed. Beyond that, once we know who is connected, we need to restrict its access. I was thinking setting an ovsdb remote to read-only would be good enough, though. Then we don't even need client-specific access controls. > > - 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. > > I would agree that you can think of the problem as 1) data store and 2) distribution mechanism, as it could make sense to split it. It actually seems like making ovn-controller a read-only client could help, too. OpenStack makes use of RabbitMQ as a transport for rpc semantics. I find the db focused approach in OVN very refreshing. It's quite different, in a good way. It's not possible to miss a message and then be totally screwed up. Instead, we effectively run a self-healing main loop constantly adapting local state to match the desired state as we keep up with the state of the DB. It's very different than how OpenStack services are built today, and could serve as a very good example for how to build new ones. It seems that RabbitMQ has been one of the largest pain points in OpenStack production deployments (though not all issues with RabbitMQ itself). The fact that OVN doesn't use it is seen as a plus to many. I would be *very* hesitant to adopt it for OVN. The OVSDB protocol seems well suited enough, to me. The current gaps are: active HA solution, unknowns around scale/performance. I feel like there's a pretty good known set of specific todo items around this, though. There has been nice progress lately. As long as people are willing to work on these items, it's not clear to me that we should abandon ovsdb-server. The other major issue that I seem to hit often than anything else is a perception issue. "What?! Why do you have your own database?!" That's going to be an ongoing uphill battle when pitching OVN. I'm willing to keep trying to counter that as long as we remain confident that it's a good solution to the problem. It would be nice to see a write up of detailed requirements and how those line up with alternatives. -- Russell Bryant _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
