Bug 1384491
Summary: | TypeError: __init__() got an unexpected keyword argument 'server_hostname' | ||
---|---|---|---|
Product: | [Retired] Beaker | Reporter: | Jaroslav Kortus <jkortus> |
Component: | lab controller | Assignee: | Martin Styk <mastyk> |
Status: | CLOSED NEXTRELEASE | QA Contact: | tools-bugs <tools-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | develop | CC: | mastyk, mjia |
Target Milestone: | 26.5 | Keywords: | Patch, Triaged |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2019-04-11 08:03:44 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jaroslav Kortus
2016-10-13 11:54:49 UTC
Which version of python-gevent was broken? Which version is working? python-gevent-1.0-2.el7.x86_64 (RHEL-extras) is broken the one pip installed was IIRC 1.1.2. Okay thanks. I have a feeling that we are passing this kwarg down conditionally (based on the Python version) expecting that the 2.7 stdlib supports it, but the gevent version is slightly older and so its monkey-patched ssl lib is not aware of that new arg. But I need to investigate more. I would agree with your analysis. I'd blame the "embedded" ssl library too, at least from what I've been able to try and google :). It would be nice if our dogfood job would set up SSL certificates (under a fake self-signed CA or something) so that the tests used https:// for everything. I assume it would reproduce this bug in that case... Anyway, it seems that EPEL7 still has gevent 1.0.1. I'm not sure if that's intentional by Orion because 1.1 has some slight incompatibilities: http://www.gevent.org/whatsnew_1_1.html#compatibility or if just because nobody ever bothered updating it... So I could try building a new gevent for EPEL7 and letting that soak in our dogfood tests for a while hmmm. Ahh nope I just remembered that gevent was retired from EPEL7 because it's in RHEL7 Extras now. With version 1.0 only. So this probably needs to be filed as a RHEL bug, assuming I can come up with a simple reproducer against gevent. I've found RHEL Bug 1416165 which shows a different problem, but would have the same outcome. The likelihood that it gets fixed is very dim, since RHEL 7.4 is already shipped. However in a quick chat with Dan there are a few possible solutions we can take: (I primarily quote Dan here) * file a better RHEL7 bug demonstrating exactly why it is broken right now and needs fixing, perhaps with a simple patch that does not mean rebasing gevent entirely (they will much more likely take that in z stream) * ship our own version of gevent that just overwrites the rhel one (in general, bad) * ship a side-by-side installable compat package containing a newer gevent (less bad but way harder) * maybe figure out what it would cost us to replace gevent with Pythons 'async' which is part of the standard library in Python3 So the way forward would be finding out which solution we would like to go, pick one and go with it. After further analysis, it seems that this issue should be applicable only for Python >= 2.7.9. Accordingly, to the documentation, they changed the constructor of ssl.SSLSocket old definition: __init__(self, sock, keyfile=None, certfile=None, server_side=False, cert_reqs=0, ssl_version=2, ca_certs=None, do_handshake_on_connect=True, suppress_ragged_eofs=True, ciphers=None) new definition: __init__(self, sock, keyfile=None, certfile=None, server_side=False, cert_reqs=0, ssl_version=2, ca_certs=None, do_handshake_on_connect=True, suppress_ragged_eofs=True, ciphers=None, server_hostname=None, _context=None) However monkey patch for SSL provided by python-gevent doesn't have this change until 1.0.2 release. I'm testing this issue on RHEL 7.6. By default, RHEL provides me Python 2.7.5 - This version will be used also in RHEL 7.7 (currently in development). |