"dev" <dev-boun...@openvswitch.org> wrote on 08/19/2016 12:07:36 AM:
> From: Numan Siddique <nusid...@redhat.com> > To: Ben Pfaff <b...@ovn.org> > Cc: ovs dev <dev@openvswitch.org> > Date: 08/19/2016 12:07 AM > Subject: Re: [ovs-dev] [PATCH 2/2] ovn/TODO: Add items proposed for > 2.7 in OVN IRC meeting. > Sent by: "dev" <dev-boun...@openvswitch.org> > > On Thu, Aug 18, 2016 at 11:44 PM, Ben Pfaff <b...@ovn.org> wrote: > > > Signed-off-by: Ben Pfaff <b...@ovn.org> > > --- > > ovn/TODO | 55 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 55 insertions(+) > > > > diff --git a/ovn/TODO b/ovn/TODO > > index b3c4831..97a5fc9 100644 > > --- a/ovn/TODO > > +++ b/ovn/TODO > > @@ -1,5 +1,60 @@ > > -*- outline -*- > > > > +* Work out database for clustering or HA properly. > > + > > +* Compromised chassis mitigation. > > + > > +Possibly depends on database solution. > > + > > +* Get incremental updates in ovn-controller and ovn-northd in some > > + sensible way. > > + > > > > ​May be the below can also be added which you mentioned in the IRC meeting > (11th August). > > ------------------ > blp regXboi: We should eventually make OVN use OpenFlow "bundles" so that > it transactionally replaces the flow table instead of deleting and then > repopulating it. > ​ > > ​---------​-------- 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. 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). 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. Thoughts? _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
