ovn/TODO

   1 * ovn-controller
   2
   3 *** Determine how to split logical pipeline across physical nodes.
   4
   5     From the original OVN architecture document:
   6
   7     The pipeline processing is split between the ingress and egress
   8     transport nodes.  In particular, the logical egress processing may
   9     occur at either hypervisor.  Processing the logical egress on the
  10     ingress hypervisor requires more state about the egress vif's
  11     policies, but reduces traffic on the wire that would eventually be
  12     dropped.  Whereas, processing on the egress hypervisor can reduce
  13     broadcast traffic on the wire by doing local replication.  We
  14     initially plan to process logical egress on the egress hypervisor
  15     so that less state needs to be replicated.  However, we may change
  16     this behavior once we gain some experience writing the logical
  17     flows.
  18
  19     The split pipeline processing split will influence how tunnel keys
  20     are encoded.
  21
  22 ** ovn-controller parameters and configuration.
  23
  24 *** SSL configuration.
  25
  26     Can probably get this from Open_vSwitch database.
  27
  28 * ovsdb-server
  29
  30   ovsdb-server should have adequate features for OVN but it probably
  31   needs work for scale and possibly for availability as deployments
  32   grow.  Here are some thoughts.
  33
  34   Andy Zhou is looking at these issues.
  35
  36 *** Reducing amount of data sent to clients.
  37
  38     Currently, whenever a row monitored by a client changes,
  39     ovsdb-server sends the client every monitored column in the row,
  40     even if only one column changes.  It might be valuable to reduce
  41     this only to the columns that changes.
  42
  43     Also, whenever a column changes, ovsdb-server sends the entire
  44     contents of the column.  It might be valuable, for columns that
  45     are sets or maps, to send only added or removed values or
  46     key-values pairs.
  47
  48     Currently, clients monitor the entire contents of a table.  It
  49     might make sense to allow clients to monitor only rows that
  50     satisfy specific criteria, e.g. to allow an ovn-controller to
  51     receive only Logical_Flow rows for logical networks on its hypervisor.
  52
  53 *** Reducing redundant data and code within ovsdb-server.
  54
  55     Currently, ovsdb-server separately composes database update
  56     information to send to each of its clients.  This is fine for a
  57     small number of clients, but it wastes time and memory when
  58     hundreds of clients all want the same updates (as will be in the
  59     case in OVN).
  60
  61     (This is somewhat opposed to the idea of letting a client monitor
  62     only some rows in a table, since that would increase the diversity
  63     among clients.)
  64
  65 *** Multithreading.
  66
  67     If it turns out that other changes don't let ovsdb-server scale
  68     adequately, we can multithread ovsdb-server.  Initially one might
  69     only break protocol handling into separate threads, leaving the
  70     actual database work serialized through a lock.
  71
  72 ** Increasing availability.
  73
  74    Database availability might become an issue.  The OVN system
  75    shouldn't grind to a halt if the database becomes unavailable, but
  76    it would become impossible to bring VIFs up or down, etc.
  77
  78    My current thought on how to increase availability is to add
  79    clustering to ovsdb-server, probably via the Raft consensus
  80    algorithm.  As an experiment, I wrote an implementation of Raft
  81    for Open vSwitch that you can clone from:
  82
  83        https://github.com/blp/ovs-reviews.git raft
  84
  85 ** Reducing startup time.
  86
  87    As-is, if ovsdb-server restarts, every client will fetch a fresh
  88    copy of the part of the database that it cares about.  With
  89    hundreds of clients, this could cause heavy CPU load on
  90    ovsdb-server and use excessive network bandwidth.  It would be
  91    better to allow incremental updates even across connection loss.
  92    One way might be to use "Difference Digests" as described in
  93    Epstein et al., "What's the Difference? Efficient Set
  94    Reconciliation Without Prior Context".  (I'm not yet aware of
  95    previous non-academic use of this technique.)