I should have also noted who was already looking at each of these items ...

On Thu, Oct 13, 2016 at 10:02 AM, Numan Siddique <nusid...@redhat.com>

> We may have to add one more item in the task breakdown list. Please see
> below
> On Wed, Oct 12, 2016 at 11:21 PM, Russell Bryant <russ...@ovn.org> wrote:
>> Hello, I'm back to looking at southbound database security concerns in
>> OVN.  A previous thread discussing approaches was here:
>>     http://openvswitch.org/pipermail/dev/2016-August/078106.html
>> I'm now working with a few others on implementing a proposed solution.
>> The overview is that we'd like to make ovn-controller a read-only client of
>> the southbound database.
>> The task breakdown is:
>> 1) Add support to ovsdb-server for read-only remotes.  The port reachable
>> by ovn-controller would only accept read-only connections.
Lance has an RFC patch posted for this.

>> 2) Remove support from ovn-controller for automatically creating chassis
>> and encap records.  Document this as an administrative step for adding a
>> new chassis to the system, instead.
Numan has a patch for this, not yet posted as I wanted to post 2-4 together.

> 3) Remove support from ovn-controller for setting the chassis column of
>> Port_Binding records.  Instead, have this handled by ovn-northd based on
>> binding instructions given in the northbound database.
>> As a nice side effect, this helps solve one of the difficulties with live
>> migration (two chassis fighting to own a port while the migration is in
>> progress).  Instead, we would update OVN when we know the migration is
>> complete.
>> I was originally thinking we may need an upgrade utility to help existing
>> environments, but I think ovn-northd can handle this automatically.
>> For the northbound database, I was thinking of adding a new option for
>> logical ports called "chassis" with a value of the hostname of the chassis
>> the port should be bound to.
I'm working on this.

> 4) Remove use of MAC_bindings table from ovn-controller.  Replace it with
>> a local cache, instead.  I'm proposing just keeping it in memory in
>> ovn-controller, but we could also make use of the openvswitch db.
>> One detail I haven't fully thought through: what should happen to the
>> MAC_Bindings table?  Dropping the table seems not backwards compatible and
>> would break a rolling upgrade scenario.  Should we leave it as unused for
>> one release, and then remove it in the next release?  More generally, I
>> think we need to document our upgrade strategy and related rules for
>> database schema changes.
Babu has a patch for this.

> ​5) Remove support from ovn-controller updating the 'Chassis.hv_cfg'
> column​ and handle the side effect in "--wait=hv" in ovn-nbctl.

Ah yes, I missed this.

My initial thought is that since this is primarily useful for testing, we
could accept this as a limitation of the feature and it just wouldn't work
if you didn't expose write access to ovn-controller.  A huge downside to
this is that if we're not enforcing read-only access in our test suite,
we're more likely to have regressions.

Any other ideas?

Russell Bryant
dev mailing list

Reply via email to