[ovs-dev] [PATCH 0/2] ovn: Make ovn-controller readonly to the Chassis and Port_Binding SB DB tables

Ben Pfaff blp at ovn.org
Mon Dec 12 20:58:56 UTC 2016


On Tue, Dec 13, 2016 at 01:43:27AM +0530, Numan Siddique wrote:
> On Mon, Dec 12, 2016 at 11:26 PM, Ben Pfaff <blp at ovn.org> wrote:
> 
> > On Fri, Nov 11, 2016 at 08:52:57PM +0530, Numan Siddique wrote:
> > > With the commit - "ovsdb-server: Implement read-only remote connection
> > type." merged, this patch series is the next step in making ovn-controller
> > a read-only client to the Southbound DB.
> > >
> > > Patch 1 removes the chassis creation code from ovn-controller. It now
> > expects the chassis row to be created in the Chassis table.
> > > Patch 2 removes the ovn-controller setting the chassis column of Port
> > binding. Instead ovn-northd will set it.
> > >
> > > Since ovn-controller is not setting the chassis column, one side effect
> > of this patchset is the Logical_Switch_Port.up doesn't reflect the
> > > true value. Is this limitation acceptable ?
> >
> > I have a couple of thoughts here.
> >
> > One is that, as we make this kind of change, we need to figure out the
> > upgrade path.  Maybe, we need to write a skeleton upgrade document (I
> > seem to recall that Russell has started on this), and then each change
> > that is relevant for upgrade needs to update the upgrade document
> > appropriately.
> >
> > I'm not super happy with the idea of Logical_Switch_Port.up being
> > inaccurate.  For one, I understand that OpenStack wants to wait until
> > networking is up for something or other.
> >
> ​Does the proposal of using ovsdb locks to set the LSP "up" or "down" seems
> OK to you. I was thinking of posting the code which I have for review after
> testing it more  thoroughly as v2 to this series.

I'm not really happy with it.  First, ovsdb-server is designed to handle
a single-digit number of locks.  The lock implementation isn't meant to
handle thousands of locks, so it's not going to scale well.  Second, I
expect that other data will come along that HVs need some control over,
and this lock-based model can't work (at least, not reasonably) with
anything that isn't a boolean.

> > Let me make a straw man proposal for how to solve this kind of problem.
> > Suppose that we abandon the idea of making OVN 100% database-driven, by
> > introducing a central RPC server.  The RPC server could be part of
> > ovn-northd, or it could be a separate daemon.  In any case, it would
> > provide specific access to the kinds of database writes that until now
> > the HVs have done directly.  For example, it would include an RPC for
> > marking an LSP "up" or "down".
>
> Another approach which comes to my mind, is it to enhance ovsdb-server to
> support in memory tables​ ? (like we can define the table to be in-memory
> in the schema). Whatever the rows added/modified by the clients will be
> lost when the ovsdb-server is restarted.
> 
> With this approach we could solve both the LSP up/down problem and mac
> binding problem.

OVSDB does support such tables but I don't see how it solves the problem
at hand.


More information about the dev mailing list