On Tue, Dec 13, 2016 at 2:28 AM, Ben Pfaff <[email protected]> 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 <[email protected]> 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 _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
