<div dir="ltr">Hi, <div><br></div><div>I'm curious if other openstack clients implement this type of retry thing. I think retrying on GET/DELETES/PUT's should probably be okay. </div><div><br></div><div>What types of errors do you see in the neutron-server when it fails to respond? I think it would be better to move the retry logic into the server around the failures rather than the client (or better yet if we fixed the server :)). Most of the times I've seen this type of failure is due to deadlock errors caused between (sqlalchemy and eventlet *i think*) which cause the client to eventually timeout. </div>
<div><br></div><div>Best, </div><div><br></div><div>Aaron</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 28, 2014 at 11:51 AM, Paul Ward <span dir="ltr"><<a href="mailto:wpward@us.ibm.com" target="_blank">wpward@us.ibm.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<p><font face="sans-serif">Would it be feasible to make the retry logic only apply to read-only operations?  This would still require a nova change to specify the number of retries, but it'd also prevent invokers from shooting themselves in the foot if they call for a write operation.<br>

<br>
</font><br>
<br>
<tt><font>Aaron Rosen <<a href="mailto:aaronorosen@gmail.com" target="_blank">aaronorosen@gmail.com</a>> wrote on 05/27/2014 09:40:00 PM:<br>
<br>
> From: Aaron Rosen <<a href="mailto:aaronorosen@gmail.com" target="_blank">aaronorosen@gmail.com</a>></font></tt></p><div class=""><br>
<tt><font>> To: "OpenStack Development Mailing List (not for usage questions)" <br>
> <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>>, </font></tt><br>
</div><tt><font>> Date: 05/27/2014 09:44 PM</font></tt><div class=""><br>
<tt><font>> Subject: Re: [openstack-dev] [neutron] Supporting retries in neutronclient</font></tt><br>
</div><tt><font>> <br>
> Hi, </font></tt><div><div class="h5"><br>
<tt><font>> <br>
> Is it possible to detect when the ssl handshaking error occurs on <br>
> the client side (and only retry for that)? If so I think we should <br>
> do that rather than retrying multiple times. The danger here is <br>
> mostly for POST operations (as Eugene pointed out) where it's <br>
> possible for the response to not make it back to the client and for <br>
> the operation to actually succeed. </font></tt><br>
<tt><font>> <br>
> Having this retry logic nested in the client also prevents things <br>
> like nova from handling these types of failures individually since <br>
> this retry logic is happening inside of the client. I think it would<br>
> be better not to have this internal mechanism in the client and <br>
> instead make the user of the client implement retry so they are <br>
> aware of failures. </font></tt><br>
<tt><font>> <br>
> Aaron </font></tt><br>
<tt><font>> <br>
</font></tt><br>
<tt><font>> On Tue, May 27, 2014 at 10:48 AM, Paul Ward <<a href="mailto:wpward@us.ibm.com" target="_blank">wpward@us.ibm.com</a>> wrote:</font></tt><br>
<tt><font>> Currently, neutronclient is hardcoded to only try a request once in <br>
> retry_request by virtue of the fact that it uses self.retries as the<br>
> retry count, and that's initialized to 0 and never changed.  We've <br>
> seen an issue where we get an ssl handshaking error intermittently <br>
> (seems like more of an ssl bug) and a retry would probably have <br>
> worked.  Yet, since neutronclient only tries once and gives up, it <br>
> fails the entire operation.  Here is the code in question:<br>
> <br>
> <a href="https://github.com/openstack/python-neutronclient/blob/master/" target="_blank">https://github.com/openstack/python-neutronclient/blob/master/</a><br>
> neutronclient/v2_0/client.py#L1296<br>
> <br>
> Does anybody know if there's some explicit reason we don't currently<br>
> allow configuring the number of retries?  If not, I'm inclined to <br>
> propose a change for just that.</font></tt><br>
<tt><font>> <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></tt><br>
<tt><font>> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</font></tt></div></div><p></p></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>