Files

Flavio Percoco 47423ebbb2 Check if v2 is available and fallback

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

2015-09-04 13:31:55 +02:00

hooks

Update path to subunit2html in post_test_hook

2015-09-04 10:29:01 +09:00

__init__.py

Create functional test base

2015-04-18 17:43:01 +00:00

base.py

Enable flake8 checks

2015-07-21 17:08:27 +03:00

README.rst

Create functional test base

2015-04-18 17:43:01 +00:00

test_readonly_glance.py

Check if v2 is available and fallback

2015-09-04 13:31:55 +02:00

README.rst

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