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

[Numan Siddique]

On Tue, Dec 13, 2016 at 2:28 AM, Ben Pfaff <blp at ovn.org> wrote:

> 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.
>

​Thanks for the comments. I agree.


> > > 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.
>

​My thought was to allow the read-only clients ​

​to modify the
in-memory tables. But I don't think this would solve the problem.

Thanks
​Numan​