[ovs-dev] weekly OVN report

[Dan Mihai Dumitriu]

On Tue, Mar 8, 2016 at 10:29 PM, Russell Bryant <russell at ovn.org> wrote:

> On Tue, Mar 8, 2016 at 3:15 AM, Amitabha Biswas <azbiswas at 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.
>

Is it possible to make ovn-controller a read-only client? I would think
that it needs to write (indicate) some information to the central
controller - e.g. for dynamic learning. Would the ovn-controller-vtep have
read-write access? If so, would it need to have full access? My gut says
that we'll conclude that we 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.
>

I think the short answer is, "because different types of data, particularly
in the SB DB, have very different consistency and durability semantics, and
there simply is no one size fits all solution." That said, the issue is
more about the access layer (which includes the issues of scalable
notifications, diffs, and access control) than about the backend (cluster)
storage layer - I think in the backend, behind the 'facade' of the access
layer, multiple storage mechanisms will need to exist, some persistent,
some not.



> It would be nice to see a write up of detailed requirements and how those
> line up with alternatives.
>
> --
> Russell Bryant
>