2ae10ce522
The placement API will initially host resource provider information and then will grow to provide a full placement service. Eventually it will be fully extracted from Nova. To facilitate that extraction, this service is being developed with few ties to existing nova.wsgi structures. Instead it uses relatively plain WSGI apps that are: * uses the Routes library with declarative mapping defined in ROUTE_DECLARATIONS * basic wsgi apps, with webob and the request class, for each handler define as functions * does not use a paste-ini file to compose middleware, instead code which minimally inspects the oslo config to know how to adjust middleware (in the initial case choosing an auth_strategy) Many of these "features" will be demonstrated in commits that follow this one that enable specific behaviors for resource providers and their inventories. In order to ensure that this change can be merged in an atomic fashion it includes microversion support that was previously in its own commit. The microversion_parse library is used in a WSGI middleware to parse incoming microversion headers and place the determined value into the WSGI environment at the 'placement.microversion' key. Response headers are adjusted to add the required outgoing headers as described in: http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html If a client requests an invalid microversion, they will receive a 400 response. If the microversion is of a valid form but not available, they will received a 406 response. The format of that response is dependent on the accept header of the request. If it is JSON, the min and max available microversions are presented. A request to '/' will return version discovery information. Thus far nothing else is done with the microversion information. It is there for when we need it in the future. For now everything is version 1.0. The groundwork for using gabbi to test the API is in place in nova/tests/functional/api/openstack/placement. The gabbi tests are included in the functional target. To run just the placement tests it is possible to run 'tox -efunctional placement'. Change-Id: Icb9c8f7a1fa8a9eac66c2d72f4b7e4efd4e1944f Partially-Implements: blueprint generic-resource-pools
19 lines
994 B
Plaintext
19 lines
994 B
Plaintext
[DEFAULT]
|
|
test_command=OS_STDOUT_CAPTURE=${OS_STDOUT_CAPTURE:-1} \
|
|
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
|
|
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-160} \
|
|
${PYTHON:-python} -m subunit.run discover -t ./ ${OS_TEST_PATH:-./nova/tests} $LISTOPT $IDOPTION
|
|
|
|
test_id_option=--load-list $IDFILE
|
|
test_list_option=--list
|
|
# NOTE(cdent): The group_regex describes how testrepository will
|
|
# group tests into the same process when running concurently. The
|
|
# following insures that gabbi tests coming from the same YAML file
|
|
# are all in the same process. This is important because each YAML
|
|
# file represents an ordered sequence of HTTP requests. Note that
|
|
# tests which do not match this regex will not be grouped in any
|
|
# special way. See the following for more details.
|
|
# http://testrepository.readthedocs.io/en/latest/MANUAL.html#grouping-tests
|
|
# https://gabbi.readthedocs.io/en/latest/#purpose
|
|
group_regex=(gabbi\.(?:driver|suitemaker)\.test_placement_api_([^_]+))
|