These particular imports are no longer needed in a Python 3-only world.
Change-Id: Ia1b60ce238713b86f126e2d404199d102fdbc5bc
Signed-off-by: Stephen Finucane <stephenfin@redhat.com>
When using PlacementFixture, we can pass some arguments to the CRUD operators.
That said, given the fake methods use kwargs, the fixture won't raise a
TypeError if the parameter name is wrong like the reportclient would do.
Adding a new decorator for verifying it.
Change-Id: Icd3f9e16ac31ea7220052770390aaf4b38e1c469
This builds on the ProviderTree work in the compute driver and
resource tracker to take the supported capabilities from a driver and
turn those into standard traits on the compute node resource provider.
This is a simple way to expose in a REST API (Placement in this case)
what a compute node, via its driver, supports.
This is also something easy that we can do in lieu of a full-blown
compute capabilities REST API in nova, which we've talked about for
years but never actually done anything about.
We can later build on this to add a request filter which will mark
certain types of boot-from-volume requests as requiring specific
capabilities, like for volume multiattach and tagged devices.
Any traits provided by the driver will be automatically added during
startup or a periodic update of a compute node:
https://pasteboard.co/I3iqqNm.jpg
Similarly any traits later retracted by the driver will be
automatically removed.
However any traits associated with capabilities which are
inappropriately added to or removed from the resource provider by the
admin via the Placement API will not be reverted until the compute
service's provider cache is reset.
The new call graph is shown in this sequence diagram:
https://pasteboard.co/I25qICd.png
Co-Authored-By: Adam Spiers <aspiers@suse.com>
Related to blueprint placement-req-filter
Related to blueprint expose-host-capabilities
Change-Id: I15364d37fb7426f4eec00ca4eaf99bec50e964b6
Currently functional tests cannot test the DELETE method on some API
endpoints, e.g.
DELETE /placement/traits/{name}
This is because it is not setting the request headers to have the
right microversion API - this setting was added for GET / PUT / POST
in I681712ac37f732c7803c68f6c7d1eae9f2877d3d, but not for DELETE.
Therefore the microversion defaults to 1.0 which for some endpoints is
lower than the required version, e.g. the endpoint above requires a
minimum microversion of 1.6, which is when this API was introduced.
This results in any invocation of _fake_delete() receiving a 404
error, although this error has not been experienced so far because
nothing uses _fake_delete() yet.
In order to enable future functional tests which hit this API call,
set the request headers in a manner consistent with the other HTTP
methods for the same endpoint.
Change-Id: I2e2d9a9ae12404fe66eae64f8767e348012d7932
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
Stephen Finucane
