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
This adds policy rules or the various /resource_classes*
routes with the default being backward compatible with
existing deployments (requires role:admin).
The "non admin forbidden non json" gabbit had to be changed
because the policy check moved so the test would fail with a
406 response instead of 403.
Part of blueprint granular-placement-policy
Change-Id: I90ef62e8e7b9e75830ac60e0c5c7e92845ab4afe
Add functional tests for resource class API
in the following cases.
* Additional properties in POST /resource_classes
* Additional properties in PUT /resource_classes/{name} (1.6)
* Earlier microversion (1.1) in the following APIs
- POST /resource_classes
- GET /resource_classes/{name}
- PUT /resource_classes/{name}
- DELETE /resource_classes/{name}
Change-Id: I7a8b0853c7580d31ab61884b10b80e5f7c8bb0b6
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
This patch is to add definition of resource class for VGPU and
VGPU_DISPLAY_HEAD, and there will be a series of patches to implement
the whole vgpu feature.
Partially Implements: blueprint add-support-for-vgpu
Change-Id: Ie363453eb9856b39e4ededc5e76807b3d165a1c5
In microversion <= 1.6 it is possible to update a resource class to have
a new name. This is only possible for custom resource classes, but there
was no test to show that the proper 400 was returned when attempting to
change a standard class.
This adds one test to cover it, and in the process changes the name of
a related test to distinguish it from the new one.
Change-Id: I6c665db68de91c0de91c16f7e622f0c7e2f28bc2
Closes-Bug: #1723123
In a microversion 1.7 change PUT /resource_classes/{name} so that
creation and existence validation of a custom resource class can
happen in a single request and prevent the previous behavior of
being able to update a single resource class to a new name, which is
not desirable.
The previous update_resource_class is still in place to support
microversion 1.2-1.6.
The original resource-classs.yaml sets the default microversion
header to 'latest' so for those existing tests that are using the
old style of PUT, a '1.6' header has been added. New files for
version 1.6 (to add a "no 1.7 behavior here" test) and 1.7 (testing
the new PUT behavior and explicitly verifying POST to create is
still around) are added.
Change-Id: I95f62ab2cb1ab76d18fb52b93f87ed28e4e7b5f3
Implements: bp placement-put-resource-class
Change decorator for resource based actions in resource_class
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: Ic330d23b2eda3b3f299291b9cdc4489d02481786
Partial-Bug: #1635182
When update resource class with existed one's name,
the exception message was formatted by the updated resource
class's name, rather than the required existed one's name.
This patch formats the message with existed one's name, and
changing tests to add the right name.
Change-Id: I78ae8d872748de243d74b9954ce634fccf5e7310
Closes-Bug: #1663163
APIs listed below are returning 500 error if you pass name more than
255 characters.
1. create resource_classes
2. update resource_classes
Added maxLength check in schema to ensure name should not be more than
255 characters.
Closes-Bug: #1648314
Change-Id: I4ae54f3061fe43d87a656088db1d2ae454eb8237
This patch adds support for a REST API for CRUD operations on custom
resource classes:
GET /resource_classes: return all resource classes
POST /resource_classes: create a new custom resource class
PUT /resource_classes/{name}: update name of custom resource class
DELETE /resource_classes/{name}: deletes a custom resource class
GET /resource_classes/{name}: get a single resource class
Change-Id: I99e7bcfe27938e5e4d50ac3005690ac1255d4c5e
blueprint: custom-resource-classes
Chris Dent