We've actually made a lot of improvements.
Signed-off-by: Ben Pfaff
---
ovn/TODO.rst | 26 --
1 file changed, 26 deletions(-)
diff --git a/ovn/TODO.rst b/ovn/TODO.rst
index 34615b9bc7d4..101a127d8054 100644
--- a/ovn/TODO.rst
+++ b/ovn/TODO.rst
@@ -25,17 +25,9 @@
OVN To-do List
==
-* Work out database for clustering or HA properly.
-
* Get incremental updates in ovn-controller and ovn-northd in some
sensible way.
-* Self-managing HA for ovn-northd (avoiding the need to set up
- independent tooling for fail-over).
-
- Russell Bryant: "For bonus points, increasing N would scale out ovn-northd if
- it was under too much load, but that's a secondary concern."
-
* Live migration.
Russell Bryant: "When you're ready to have the destination take over, you
@@ -61,12 +53,6 @@ OVN To-do List
* Use OpenFlow "bundles" for transactional data plane updates.
-* L3 support
-
- * Logical routers should send RST replies to TCP packets.
-
- * IPv6 router ports should periodically send ND Router Advertisements.
-
* Dynamic IP to MAC binding enhancements.
OVN has basic support for establishing IP to MAC bindings dynamically, using
@@ -114,18 +100,6 @@ OVN To-do List
only break protocol handling into separate threads, leaving the
actual database work serialized through a lock.
- * Increasing availability.
-
-Database availability might become an issue. The OVN system shouldn't
-grind to a halt if the database becomes unavailable, but it would become
-impossible to bring VIFs up or down, etc.
-
-My current thought on how to increase availability is to add clustering to
-ovsdb-server, probably via the Raft consensus algorithm. As an experiment,
-I wrote an implementation of Raft for Open vSwitch that you can clone from:
-
- https://github.com/blp/ovs-reviews.git raft
-
* Reducing startup time.
As-is, if ovsdb-server restarts, every client will fetch a fresh copy of
--
2.16.1
___
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev