[ovs-dev] RFC: OVN database options

[Ben Pfaff]

On Fri, Mar 11, 2016 at 12:13:25PM -0500, Mike Bayer wrote:
> On 03/10/2016 06:50 PM, Ben Pfaff wrote:
> >
> >I've been a fan of Postgres since I used in the 1990s for a web-based
> >application.  It didn't occur to me that it was appropriate here.
> >Julien, thanks so much for joining the discussion.
> >
> >>>So yes, it has everything OVN needs. It can push notifications to
> >>>clients via the NOTIFY¹ command (that you can use in any
> >>>procedure/trigger). For example, you could imagine creating a trigger
> >>>that sends a JSON payload for each new update/insert in the database.
> >>>That's literally 10 lines of PL/SQL.
> >
> >That's good to know.  I hadn't figured out how to do this kind of thing
> >with SQL-based systems.
> >
> >>>¹  http://www.postgresql.org/docs/9.5/static/sql-notify.html
> >>>
> >>>I think that PostgreSQL would be the safer bet in this move, as:
> >>>- building something on top of etcd would seem weak w.r.t your
> >>>schema/table requirements
> >>>- investing in OVSDB (though keep in mind I don't know it :-) would
> >>>probably end up in redoing a job PostgreSQL people already have done
> >>>better than you would ;-)
> >>>
> >>>The only questions that this raises to me are:
> >>>- whether PostgreSQL is too large/complex to deploy for OVN. Seeing the
> >>>   list of candidates that were evaluated, I wouldn't think so, but there
> >>>   can be a lot of different opinions on that based on different
> >>>   perception of PostgreSQL. And since you're targeting a network DB, you
> >>>   definitely need a daemon configured and set-up so I'm only partially
> >>>   worried here. :)
> 
> Hi there, Russell Bryant invited me to this list to chime in on this
> discussion.   If it were me, I *might* not build out based on NOTIFY as the
> core system of notifying clients, and I'd likely stick with a tool
> that's designed for cluster communication and in this case the custom
> service that's already there seems like it might be the best bet; I'd
> actually build out the service and use RAFT to keep it in sync with itself.
> 
> The reason is because Postgresql is not supplying you with an easy
> out-of-the-box HA component in any case (Galera does, but then you don't get
> NOTIFY), so you're going to have to build out something like RAFT or such on
> the PG side in any case in order to handle failover. Postgresql's HA story
> is not very good right now, it's very much roll-your-own, and it is nowhere
> near the sophistication of Galera's multi-master approach which would be an
> enormous muilt-year undertaking to recreate on Posgtresql.     IMO building
> out the HA part from scratch is the difficult part; being able to send
> events to clients is pretty easy from any kind of custom service.   Since to
> do HA in PG you'd have to build your own event-dispatch system anyway (e.g.
> to determine a node is down and send out the call to pick a new master node
> as well as some method to get all the clients to send data updates to this
> node), might as well just build your custom service to do just the thing you
> need.

Thanks a lot for the comments!  I've added this to my notes.