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.
> 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. Such an RPC server would essentially be stateless, since it would just > be a database client without internal state of its own, and thus it > would work OK to run any number of copies of it without special > synchronization or HA support. > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
