ovn/TODO

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