[ovs-dev] weekly OVN report

[Dan Mihai Dumitriu]

Hi Russell,

Nice writeup of the issues and potential solutions. We have been thinking
along the same lines.

Cheers,
Dan


On Mon, Mar 7, 2016 at 11:29 PM, 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.
>>
>> That said, if the current OVSDB doesn't have an ACL model, I have some
>> security and robustness concerns, once it's run at scale. Has it been
>> considered to add an ACL model to OVSDB?
>>
>
> I've put some thought into the security concerns of the southbound
> database.  I wrote a bit about this in the ovn/TODO file.  See "limiting
> the impact of a compromised chassis".
>
> https://github.com/openvswitch/ovs/blob/master/ovn/TODO#L128
>
> Since writing that, I've come to think that as a first step, making
> ovn-controller (at least optionally) only have read-only access to the
> southbound database would be a good step.  This would require:
>
>  - Instead of having ovn-controller create the Chassis and Encap rows for
> itself, make that an administrative task when bring a new chassis online.
> This can be done with the ovn-sbctl utility.  It's data that is set once
> and very rarely changed.
>
>  - Move the job of assigning port bindings.  Right now ovn-controller sees
> ports appear locally and automatically matches them up with OVN logical
> ports and updates the port bindings.  This is quite convenient, but we
> could optionally force an external entity to define the port bindings
> instead.  In the case of OpenStack, the Neutron plugin could do this.  In
> fact, Neutron already expects to be in charge of port-host bindings, and we
> just ignore that for OVN right now.
>
> If we take that route, this doesn't seem too hard to do.
>
> --
> Russell Bryant
>