[ovs-dev] ovn: Improving southbound database security
Numan Siddique
nusiddiq at redhat.com
Thu Oct 13 14:02:53 UTC 2016
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 <russell at 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.
>
> 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.
>
> 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.
>
> 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.
>
>
5) Remove support from ovn-controller updating the 'Chassis.hv_cfg'
column and handle the side effect in "--wait=hv" in ovn-nbctl.
--
> Russell Bryant
>
More information about the dev
mailing list