Commit Graph

8 Commits

Author SHA1 Message Date
Chris Dent 787bb33606 Use external placement in functional tests
Adjust the fixtures used by the functional tests so they
use placement database and web fixtures defined by placement
code. To avoid making redundant changes, the solely placement-
related unit and functional tests are removed, but the placement
code itself is not (yet).

openstack-placement is required by the functional tests. It is not
added to test-requirements as we do not want unit tests to depend
on placement in any way, and we enforce this by not having placement
in the test env.

The concept of tox-siblings is used to ensure that the
placement requirement will be satisfied correctly if there is a
depends-on. To make this happen, the functional jobs defined in
.zuul.yaml are updated to require openstack/placement.

tox.ini has to be updated to use a envdir that is the same
name as job. Otherwise the tox siblings role in ansible cannot work.

The handling of the placement fixtures is moved out of nova/test.py
into the functional tests that actually use it because we do not
want unit tests (which get the base test class out of test.py) to
have anything to do with placement. This requires adjusting some
test files to use absolute import.

Similarly, a test of the comparison function for the api samples tests
is moved into functional, because it depends on placement functionality,

TestUpgradeCheckResourceProviders in unit.cmd.test_status is moved into
a new test file: nova/tests/functional/test_nova_status.py. This is done
because it requires the PlacementFixture, which is only available to
functional tests. A MonkeyPatch is required in the test to make sure that
the right context managers are used at the right time in the command
itself (otherwise some tables do no exist). In the test itself, to avoid
speaking directly to the placement database, which would require
manipulating the RequestContext objects, resource providers are now
created over the API.

Co-Authored-By: Balazs Gibizer <balazs.gibizer@ericsson.com>
Change-Id: Idaed39629095f86d24a54334c699a26c218c6593
2018-12-12 18:46:49 +00:00
Tetsuro Nakamura e4923abaeb Increase max_unit in placement test fixture
In the AllocationFixture setup, to avoid the limitation of the
max_unit that is set to the inventory, we were using a bit hacky
way creating multiple allocation objects that have the same resource
class, the same consumer, and the same resource provider.

Since this is not how it works in real cases, and this prevents us
from refactoring, this patch fixes it.

Change-Id: I8ba378ff5eeaf6c9cca11c5874708a17d4640097
2018-08-02 14:00:45 +09:00
Eric Fried 388db7e6e2 placement: Return new provider from POST /rps
To facilitate opaqueness of resource provider generation internals, we
need to return the (initial) generation when a provider is created. For
consistency with other APIs, we will do this by returning the entire
resource provider record (which includes the generation) from POST
/resource_providers.

Change-Id: I8624e194fe0173531c5aa2119c903e3c68b8c6cd
blueprint: generation-from-create-provider
2018-03-14 17:08:55 -05:00
Eric Fried 3216f078d4 placement: generation in provider aggregate APIs
Placement API microversion 1.19 enhances the payloads for the `GET
/resource_providers/{uuid}/aggregates` response and the `PUT
/resource_providers/{uuid}/aggregates` request and response to be
identical, and to include the ``resource_provider_generation``. As with
other generation-aware APIs, if the ``resource_provider_generation``
specified in the `PUT` request does not match the generation known by
the server, a 409 Conflict error is returned.

Change-Id: I86416e35da1798cdf039b42c9ed7629f0f9c75fc
blueprint: placement-aggregate-generation
2018-03-14 17:08:52 -05:00
Chris Dent f974e3c356 [placement] avoid case issues microversions in gabbits
If a gabbi file sets a default microversion by setting a header
'OpenStack-API-Version' with a value like 'placement latest' and then
later overrides that in an individual test with a header of
'openstack-api-version' the difference in case can lead to failure.

In the best case the failure is consistent.

In the worst case it can sometimes work, because the header shows up
twice in the request, and the last header wins, order in the headers
and the resulting list dependent on the vagrancies of python ordering.

The solution is to always use the same case, so this change updates
all use to be lowercase, to establish a precedent that future people
will be able to use as an example.

Note that gabbi is case sensitive here in part because of the
implementation but also because it provides the control and possibility
to test exactly this problem.

Change-Id: I1e89e231cf0d46d211d360cda091b33520f85027
Closes-Bug: #1728934
2017-10-31 12:54:17 +00:00
Chris Dent 643ed234da [placement] Confirm that empty resources query causes 400
When a request is made to /resource_providers or /allocation_candidates
with a 'resources' query parameter, and empty value should lead to a
400. This was indeed happening, but there was no gabbi test coverage for
it. This adds tests at both URLs.

Note that because the query parameter is processed by the same code for
both /resource_providers and /allocation_candidates the test duplicates
a code a path, however, that's an implementation detail that we don't
know at the HTTP API layer.

Change-Id: Ia6fc0ac09efc5407a899de4215a2ba0ba0b017fb
Closes-Bug: #1723122
2017-10-12 15:29:38 +01:00
Pushkar Umaranikar 14ed7ad64d Placement api: set custom json_error_formatter in resource_provider
Change decorator for resource based actions in resource_provider
handler to wsgi_wrapper.PlacementWsgify

This is a newly introduced wrapper class around webob.dec.wsgify
to set json formatter in case of webob exceptions.

Change-Id: I18b062bf4e53a2ea4c2f7e4d8b205f8fe8a7513d
Partial-Bug: #1635182
2017-02-13 16:56:51 +00:00
Sylvain Bauza a5dc7f1a11 Expose a REST API for a specific list of RPs
Now that we merged the object method for getting the list of ResourceProviders
based on a specific amount request, we need to expose that method into a REST
API call so that the scheduler client could be calling it.

Co-Authored-By: Jay Pipes <jaypipes@gmail.com>

Change-Id: Ia8b534d20c064eb3a767f95ca22814925acfaa77
Implements: blueprint resource-providers-get-by-request
2017-01-13 17:57:29 -05:00