README.rst file for functional tests and glanceclient itself
raises some warnings when passing these docs through REST
validator and build the doc:
- Need additional empty line to provide correct indent in
cloud.yaml example
- Title should be with the same length as overline.
The patch fixes these warnings.

Change-Id: I2e2ef6f838ee639d1a88256b6e321181a62cc76b

Nowadays Glance supports more subcommands.
Closes-Bug: #1520585

Change-Id: Ic95c26df31dc3bfb4436969e728f7a1a7c50ff0c

Added new items in 'wanted_commands'.

Related bug: #1508356

Change-Id: I21ca66d51ace18ac58d33d5d542f805150cb8e4f

Change-Id: I824f6cd2aa988ed1e4025765971161b44993f00a

devstack produces a file called clouds.yaml already with credentials in
it. Rather than producing our own config file to run functional tests,
just consume the clouds.yaml file that's already there.

Closes-Bug: #1507386
Change-Id: I82c071b2cd903b9578d1f2ec515882c815812692

The `_cache_schemas` call currently forces authentication even when the
`auth_token` and `os_image_url` are passed. Instead of handling forced
authentications, let the client use the passed arguments and
authenticate only once if needed.

This was not caught by the existing tests because the call to
`_cache_schemas` was mocked.

Change-Id: I93cec9a68cafc0992d14dab38114d03e25f1e5da
Closes-bug: #1490462

We have a basic implementation for a fallback mechanism that will use v1
rather than v2 when downloading schema files from glance-api fails.
However, this is not sound. If the schemas are cached already, we won't
check if v2 is available and fail to fallback.

This patch fixes the aforementioned issue by getting the list of
available versions from the server only when the API versions was not
explicitly specified through the CLI. That is, for all commands that
don't pass `--os-image-api-version 2`, we'll check v2's availability and
we'll fallback to v1 if it isn't available.

This patch also changes how we handle `/versions` calls in the client.
The server has been, incorrectly, replying to requests to `/version`
with a 300 error, which ended up in the client re-raising such
exception. While I think 300 shouldn't raise an exception, I think we
should handle that in a spearate patch. Therefore, this patch just
avoids raising such exception when `/version` is explicitly called.

This fallback behaviour and the check on `/versions` will be removed in
future versions of the client. The later depends on this bug[0] being
fixed.

[0] https://bugs.launchpad.net/glance/+bug/1491350

Closes-bug: #1489381
Change-Id: Ibeba6bc86db2a97b8a2b4bd042248464cd792e5e

Per:

http://lists.openstack.org/pipermail/openstack-dev/2015-August/072982.html

The location of subunit2html changed on the images in the gate
so update the path used in the post_test_hook.

Long-term we should just use what's in devstack-gate.

Change-Id: I142b3c0590ba2fa880973b0ee306ebd1db27fd03
Closes-Bug: #1491646

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