Some extra steps to help diagnose the problem http://stackoverflow.com/questions/18578439/using-requests-with-tls-doesnt-give-sni-support
On Sat, Apr 1, 2017 at 2:19 PM, anthony shaw <[email protected]> wrote: > May be related to downstream issues with SNI in requests/urllib3. > > Which version of requests are you using? https://github.com/ > kennethreitz/requests/issues/749#issuecomment-19187417v > > Also, in <2.0 the default behaviour to allow badly signed certificates was > changed. > > On Sat, Apr 1, 2017 at 1:50 PM, anthony shaw <[email protected]> > wrote: > >> Any luck with the debugging Markos >> >> On Thu, Mar 9, 2017 at 9:42 PM, Markos Gogoulos <[email protected]> >> wrote: >> >>> Hi all, >>> >>> I'm using the latest trunk, and the OpenStack driver is not working. I >>> believe this has to do with the recent major changes on >>> base.py/httplib_ssl.py , I'm trying to debug this now and will open a >>> PR if >>> I find something. >>> >>> After some initial quick debugging, the driver is initiated, >>> authentication >>> works, but when it tries to ask the servers the compute endpoint is not >>> what it has taken out of keystone but self.connection.host has gotten a >>> value of 127.0.0.1 and so the call to compute endpoint cannot take place. >>> >>> If you have any clues or if this addressed already please let me know. 2 >>> days ago I saw that Azure compute driver has been broken too, this is >>> based >>> on a certificate so I believe chances are that other drivers that use >>> certificates (as Docker TLS) might have problems as well. >>> >>> Regards, >>> Markos >>> >> >> >
