On Sat, Aug 13, 2016 at 11:12:18PM -0700, Jesse Gross wrote: > I think the code is reasonably robust at this point and certainly it > fixes a number of existing bugs. However, the truth is that I wasn't > really all that happy about it. It took a fairly long time to work > through the various corner cases and all of this was to support what > is really quite simple "business logic" in the mapping between the > Southbound and OVS databases. I tried to separate out the > synchronization and logic as much as possible so future changes should > be easier but this definitely doesn't feel like the best long term > solution to me. I suspect that there might be similar issues in other > places where incremental processing tries to avoid doing a full walk > of database tables. > > I can definitely see the benefits of nlog or another rule engine to > managing the synchronization. I don't yet have a good concept of how > the generic engine will map onto specific pieces of translation or how > easy it will be to adapt to different components (i.e. ovn-northd vs. > ovn-controller and all of their individual pieces). However, I'm > certainly more enthusiastic about the concept than I have been in the > past.
My general impression of ovn-controller is that it's currently hard to understand and trending toward catastrophe. It's one of my highest priorities for this next cycle. I have some ideas for a rule engine. One concept I want to play with is to integrate a database join engine into the IDL itself, where the IDL takes the database rows it receives in particular tables and then joins them into a table that it synthetically constructs and presents to the client as if it were an ordinary database table, that allows tracking etc. I haven't worked the idea out fully at all. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
