[ovs-dev] another possible cause of incremental update problems

Ben Pfaff blp at ovn.org
Sat Aug 20 19:06:29 UTC 2016


On Sat, Aug 20, 2016 at 11:43:08AM -0500, Ryan Moats wrote:
> 
> 
> Ben Pfaff <blp at ovn.org> wrote on 08/20/2016 10:32:50 AM:
> 
> > From: Ben Pfaff <blp at ovn.org>
> > To: Ryan Moats/Omaha/IBM at IBMUS
> > Cc: ovs dev <dev at openvswitch.org>
> > Date: 08/20/2016 10:33 AM
> > Subject: another possible cause of incremental update problems
> >
> > There are additional possible causes of incremental update problems that
> > I haven't previously seen mentioned here.  If you look at the functions
> > that implement incremental update, they tend to start with:
> >
> >     if (!ctx->ovnsb_idl_txn) {
> >         return NULL;
> >     }
> >
> > or similar.  This makes sense, because there is no point in composing an
> > update if it can't be committed.  However, because the main loop call
> > ovsdb_idl_txn_clear() on every iteration, that means that any updates
> > from this iteration will be lost.
> >
> > Also, transactions can fail.  In that case, the transaction needs to be
> > recomposed and retried.  ovn-controller currently doesn't have any
> > mechanism for that.
> 
> Yep, there are all sorts of interesting failure modes, but the key point
> I was looking to make with the analysis was that *even if everything
> worked perfectly* the code doesn't buy us what I hoped it would buy when
> I started - it ended up in a different place where the tradeoff no
> longer makes sense to me... (c'est la vie)

It happens.

> As a side note, I have the revert change done and I'll be sending that
> out shortly. The quiet mode change isn't passing all of the current unit
> test cases (yet), so I'm still looking at it.  I plan on sending it out
> on Monday, either as a real change if I figure out what's going wrong
> in the unit tests or as an RFC if I don't...

OK, I'll look forward to the patches.



More information about the dev mailing list