[ovs-dev] RFC: OVN database options

[Mike Bayer]

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.