<div dir="ltr"><div><br></div><div>I don't think anyone would be complaining if glanceclient didn't have the need to reach into and monkeypatch requests's connection pool manager[1]. Is there a way to tell requests to build the https connections differently without monkeypatching urllib3.poolmanager?<br><br>glanceclient's monkeypatching of the global variable here is dangerous since it will mess with the application and every other library if the application or another library uses glanceclient.<br></div><div><br>[1] <a href="http://git.openstack.org/cgit/openstack/python-glanceclient/tree/glanceclient/common/https.py#n75">http://git.openstack.org/cgit/openstack/python-glanceclient/tree/glanceclient/common/https.py#n75</a><br><br></div><div>- Brant<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 19, 2014 at 10:33 AM, Ian Cordasco <span dir="ltr"><<a href="mailto:ian.cordasco@rackspace.com" target="_blank">ian.cordasco@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 9/19/14, 9:01 AM, "Jeremy Stanley" <<a href="mailto:fungi@yuggoth.org">fungi@yuggoth.org</a>> wrote:<br>
<br>
>On 2014-09-18 14:35:10 +0000 (+0000), Ian Cordasco wrote:<br>
>> Except that even OpenStack doesn’t pin requests because of how<br>
>> extraordinarily stable our API is.<br>
>[...]<br>
><br>
>FWIW, I nearly capped it a few weeks ago with<br>
><a href="https://review.openstack.org/117848" target="_blank">https://review.openstack.org/117848</a> but since the affected projects<br>
>were able to rush in changes to their use of the library to work<br>
>around the ways it was breaking I ended up abandoning that. Also for<br>
>some months we capped requests in our global requirements because of<br>
><a href="https://launchpad.net/bugs/1182271" target="_blank">https://launchpad.net/bugs/1182271</a> but that was finally lifted about<br>
>a year ago with <a href="https://review.openstack.org/37461" target="_blank">https://review.openstack.org/37461</a> (so I don't think<br>
>it's entirely fair to assert that "OpenStack doesn’t pin requests<br>
>because...extraordinarily stable").<br>
>--<br>
>Jeremy Stanley<br>
<br>
</span>A) Not the thread for this discussion.<br>
B) I didn’t say that OpenStack *never* pinned it, I said it didn’t<br>
currently<br>
C) Did you read the whole thread? I mentioned 2.4.0 as an exception<br>
because of ProtocolErrors and the redirect_cache members of OpenStack<br>
lobbied for.<br>
D) Before someone else replies, I assumed the transition from 0.x -> 1.0<br>
was also the other obvious (and not worth mentioning) break in stability<br>
given that since then we’ve had no API changes (with the exception of<br>
2.4.0 not re-wrapping a single urllib3 exception).<br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>