[ovs-dev] [PATCH] ovs-xapi-sync: Add retries while getting single bridge ids.

Ben Pfaff blp at nicira.com
Sat Jun 15 02:38:16 UTC 2013


On Fri, Jun 14, 2013 at 07:03:39PM -0700, Ben Pfaff wrote:
> On Fri, Jun 14, 2013 at 09:52:59AM -0700, Gurucharan Shetty wrote:
> > When there are multiple xs-network-uuids set for a bridge,
> > we query xapi to get the record that does not have a VLAN
> > associated with it. For cases when xapi does not respond,
> > retry a few times and log the failures.
> > 
> > If after the retries, we still do not get the correct record,
> > set the external_ids:bridge_id as empty("").
> > 
> > Bug #17877.
> > Signed-off-by: Gurucharan Shetty <gshetty at nicira.com>
> 
> I wonder whether this is the best way to do retry.  Five retries over
> five seconds seems pretty arbitrary.  What if XAPI takes more than 5
> seconds to restart?  I think that, then, we'll take "" as the bridge-id
> and cache it.
> 
> If you think that this is a valid objection, then another approach would
> be to use "" (or None) as the bridge-id immediately (without retrying),
> but not to cache the bridge-id and, in the next iteration of the main
> loop, wait at most 1 second before starting the next transaction.  Then,
> we would continue to retry (indefinitely) without blocking all database
> updates in the meantime.

Guru, you pointed out off-list that in fact we're not caching the XAPI
responses here.  But I think that a lot of my points still apply.  Let
me try again from the top.

I wonder whether this is the best way to do retry.  Five retries over
five seconds seems pretty arbitrary.  What if XAPI takes more than 5
seconds to restart?  I think that, then, we won't notice when XAPI
really does complete its restart, at least until the next OVSDB change
that ovs-xapi-sync is interested in.  I think that could be a long time
in some cases.

If you think that this is a valid objection, then another approach would
be to use "" (or None) as the bridge-id immediately (without retrying),
and, in the next iteration of the main loop, wait at most 1 second
before starting the next transaction.  Then, we would bound the refresh
time to 1 second after XAPI completes its restart.



More information about the dev mailing list