On Sat, Aug 20, 2016 at 11:43:08AM -0500, Ryan Moats wrote:
>
>
> Ben Pfaff <b...@ovn.org> wrote on 08/20/2016 10:32:50 AM:
>
> > From: Ben Pfaff <b...@ovn.org>
> > To: Ryan Moats/Omaha/IBM@IBMUS
> > Cc: ovs dev <dev@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.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
