On Fri, Aug 19, 2016 at 08:34:45AM -0500, Ryan Moats wrote: > We've been running incremental processing in ovn-controller here for quite > a while (even before it merged officially) and given our experience, > I've been doing some hard thinking about it. > > The original goal of the patch set was to allow ovn-controller to use > incremental updates as much as possible. However, the range of possible > changes in inputs resulted in ovn-controller having to continue to > maintain the ability to run a full update in those cases where previously > calculated rules are no longer correct. > > What we've found is that most configuration events from our CMS (Neutron) > end up triggering a full ovn-controller update, and so the end result of > the incremental processing code is not that ovn-controller is doing > incremental updates most of the time, but rather that ovn-controller > doesn't recalculate changes in-between modifications. > > While we still feel that the above is a win, I'm coming to the conclusion > that the current code base has added unnecessary complexity to achieve > this. Based on this, I'm thinking of the following approach: > > 1) going back to doing full processing every cycle, while still > keeping the persistence of items where we can, because I feel that > persistence has allowed us to handle cases where we need to skip a poll > cycle that we didn't have before and that has improved things.
What I'm hearing here is that we'll do full processing if any processing at all is necessary. Seems fine to me. > 2) introducing a new command flag to allow those that don't want to > run in what I'm now calling quiet mode to continue to do full processing > every cycle. (In retrospect, I should have proposed this up front for i-p > to allow for better isolation of that code, but as they say, hindsight > is always 20/20). Hmm. I would hope that "Full processing if any processing" is fairly easy to get right. However, I'm OK with having a flag as a fail-safe. In time, I would hope that we could delete the flag. > 3) For quiet mode, check the integration bridge and Ben's sequence > number information in the SB database to determine if anything has > changed since the last cycle. If something has changed, run the full > processing code. If not, quiesce for a poll cycle. I don't think that the sequence numbers are a good way to determine whether something has changed. Without --wait, for example, ovn-nbctl doesn't change the sequence number. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
