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

Gurucharan Shetty shettyg at nicira.com
Sat Jun 15 03:03:12 UTC 2013


On Fri, Jun 14, 2013 at 7:38 PM, Ben Pfaff <blp at nicira.com> wrote:

> 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.
>
Okay. I think it is a valid objection. How about the following incremental?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20130614/88adaa73/attachment-0004.html>


More information about the dev mailing list