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