
Custom SSL handling was introduced because disabling SSL layer compression provided an approximately five fold performance increase in some cases. Without SSL layer compression disabled the image transfer would be CPU bound -- with the CPU performing the DEFLATE algorithm. This would typically limit image transfers to < 20 MB/s. When --no-ssl-compression was specified the client would not negotiate any compression algorithm during the SSL handshake with the server which would remove the CPU bottleneck and transfers could approach wire speed. In order to support '--no-ssl-compression' two totally separate code paths exist depending on whether this is True or False. When SSL compression is disabled, rather than using the standard 'requests' library, we enter some custom code based on pyopenssl and httplib in order to disable compression. This patch/spec proposes removing the custom code because: * It is a burden to maintain Eg adding new code such as keystone session support is more complicated * It can introduce additional failure modes We have seen some bugs related to the 'custom' certificate checking * Newer Operating Systems disable SSL for us. Eg. While Debian 7 defaulted to compression 'on', Debian 8 has compression 'off'. This makes both servers and client less likely to have compression enabled. * Newer combinations of 'requests' and 'python' do this for us Requests disables compression when backed by a version of python which supports it (>= 2.7.9). This makes clients more likely to disable compression out-of-the-box. * It is (in principle) possible to do this on older versions too If pyopenssl, ndg-httpsclient and pyasn1 are installed on older operating system/python combinations, the requests library should disable SSL compression on the client side. * Systems that have SSL compression enabled may be vulnerable to the CRIME (https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2012-4929) attack. Installations which are security conscious should be running the Glance server with SSL disabled. Full Spec: https://review.openstack.org/#/c/187674 Blueprint: remove-custom-client-ssl-handling Change-Id: I7e7761fc91b0d6da03939374eeedd809534f6edf
python-glanceclient functional testing |
Idea
Run real client/server requests in the gate to catch issues which are difficult to catch with a purely unit test approach.
Many projects (nova, keystone...) already have this form of testing in the gate.
Testing Theory
Since python-glanceclient has two uses, CLI and python API, we should have two sets of functional tests. CLI and python API. The python API tests should never use the CLI. But the CLI tests can use the python API where adding native support to the CLI for the required functionality would involve a non trivial amount of work.
Functional Test Guidelines
Consume credentials via standard client environmental variables:
OS_USERNAME OS_PASSWORD OS_TENANT_NAME OS_AUTH_URL
Try not to require an additional configuration file