On Thu, Mar 10, 2016 at 04:15:13PM +0200, Liran Schour wrote:
> I'd like to raise the following issues for discussion:
>
> 1. That the client side is abstracted from the specific choice of
> server-side database by using a db-abstraction layer on the client side.
> We already have some kind of an abstraction layer in the code: ovsdb-idl.
> Maybe we can start from there.
I think that this issue is orthogonal to the question of which database
or databases are suitable for OVN, and can be discussed separately.
> 2. I think if clients receive all updates this will pose a scalability
> concern. I'd like to propose adding a pub/sub-like subsystem to be used
> for keeping clients up-to-date about updates in the DB. This can serve as
> a mechanism for table tracking and could also enable clients to receive
> updates only on a small subset of changes instead of all changes. This
> would greatly improve scalability in number of clients.
If clients receive updates that they do not need, that can be a
scalability problem. Currently, OVN clients do receive some updates
that they do not need. However, the "conditional monitoring" patches
(currently under review) should allow us to fix that. I don't know how
that differs from what you're proposing; to me, it sounds the same.
> 3. Do we really need an on-disk DB for the southbound DB? I think an
> in-memory DB for the Southbound is worth discussing.
OVSDB is an in-memory DB.
I think that this my summary covers this:
- Transactions: Clients expect atomic, consistent, isolated
transactions.
Durability is not essential, because the clients will reissue
lost transactions (up to and including completely refilling an
empty database, although this can be slow).
- High availability: If the database server goes down, then this
freezes the OVN configuration. This is OK briefly for running
clients--the existing configuration continues to work, it just
can't be updated--but it prevents new clients or clients that
restart from using OVN at all.
For the same reason that durability is not essential, it is
acceptable if an occasional fail-over between database servers
loses a few transactions, though of course it's best to minimize
the probability and the amount of data lost.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
