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
/reshaper provides a way to atomically modify some allocations and
inventory in a single transaction, allowing operations like migrating
some inventory from a parent provider to a new child.
A fair amount of code is reused from handler/inventory.py, some
refactoring is in order before things get too far with that.
In handler/allocation.py some code is extracted to its own methods
so it can be reused from reshaper.py.
This is done as microversion 1.30.
A suite of gabbi tests is provided which attempt to cover various
failures including schema violations, generation conflicts, and
data conflicts.
api-ref, release notes and rest history are updated
Change-Id: I5b33ac3572bc3789878174ffc86ca42ae8035cfa
Partially-Implements: blueprint reshape-provider-tree
The tests are very straightforward and do not require any of the setup
and fixtures that nova.test.NoDBTestCase supplies. Also, in the future
of placement extraction we don't want the dependecy.
Partially implements blueprint placement-extract
Change-Id: I05498a30646d8e718c700fcedff4657907062982
That change extracts much of the microversion handling code from
placement and uses code from the microversion-parse library instead.
The code in microversion-parse was taken from placement and lightly
adjusted to make it more generally useful.
Depends-On: https://review.openstack.org/555332
Change-Id: I5a70ebf2843d2b50dccb44e66d50e1e5105005f4
raise_http_status_code_if_not_version are duplicate
we don't need keep this function, instead, use
the decorater to check version.
Also, fixed a typo in comment as well.
Change-Id: Ie7200dbfb863d27115e12347e0e8b4ad444489e1
This provides microversion 1.13 of the placement API, giving the
ability to POST to /allocations to set (or clear) allocations for
more than one consumer uuid.
It builds on the recent work to support a dict-based JSON format
when doing a PUT to /allocations/{consumer_uuid}.
Being able to set allocations for multiple consumers in one request
helps to address race conditions when cleaning up allocations during
move operations in nova.
Clearing allocations is done by setting the 'allocations' key for a
specific consumer to an empty dict.
Updates to placement-api-ref, rest version history and a reno are
included.
Change-Id: I239f33841bb9fcd92b406f979674ae8c5f8d57e3
Implements: bp post-allocations
A new 1.10 API microversion is added to return information that the
scheduler can use to select a particular set of resource providers to
claim resources for an instance.
The GET /allocation_candidates endpoint takes a "resources" querystring
parameter similar to the GET /resource_providers endpoint and returns a
dict with two top-level elements:
"allocation_requests" is a list of JSON objects that contain a
serialized HTTP body that the scheduler may subsequently use in a call
to PUT /allocations/{consumer_uuid} to claim resources against a
related set of resource providers.
"provider_summaries" is a JSON object, keyed by resource provider UUID,
of JSON objects of inventory/capacity information that the scheduler
can use to sort/weigh the results of the call when making its
destination host decisions.
Change-Id: I8dadb364746553d9495aa8bcffd0346ebc0b4baa
blueprint: placement-allocation-requests
This adds GET /usages as part of a new microversion 1.9 of the
placement API. Usages can be queried by project or project/user:
GET /usages?project_id=<project id>
GET /usages?project_id=<project id>&user_id=<user id>
and will be returned as a sum of usages, for example:
200 OK
Content-Type: application/json
{
"usages": {
"VCPU": 2,
"MEMORY_MB": 1024,
"DISK_GB": 50,
...
}
}
A new method UsageList.get_all_by_project_user() has been added
for usage queries.
Part of blueprint placement-project-user
Change-Id: I8b948a4dfe6a50bea053b5dcae8f039229e2e364
This adds project_id and user_id required request parameters as part of
a new microversion 1.8 of the placement API.
Two new fields, for project and user ID, have been added to the
AllocationList object, and the method AllocationList.create_all() has
been changed to ensure that records are written to the consumers,
projects, and users tables when project_id and user_id are not None.
After an upgrade, new allocations will write consumer records and
existing allocations will have corresponding consumer records written
when they are updated as part of the resource tracker periodic task for
updating available resources.
Part of blueprint placement-project-user
Co-Authored-By: Jay Pipes <jaypipes@gmail.com>
Change-Id: I3c3b0cfdd33da87160255ead51a0d9ff73667655
It is easy to make mistake when added multiple versioned methods and it
generates a gap between mulitple versioned methods. This test ensures no
gap between each versioned method.
Change-Id: Ib91eba000ecd4ce28f51e44cc74be32fc2200a2f
This patch adds support for a REST API for CRUD operations on traits.
GET /traits: Returns all resource classes.
PUT /traits/{name}: To insert a single custom trait.
GET /traits/{name}: To check if a trait name exists.
DELETE /traits/{name}: To delete the specified trait.
GET /resource_providers/{uuid}/traits: a list of traits associated
with a specific resource provider
PUT /resource_providers/{uuid}/traits: Set all the traits for a
specific resource provider
DELETE /resource_providers/{uuid}/traits: Remove any existing trait
associations for a specific resource provider
Partial implement blueprint resource-provider-traits
Change-Id: Ia027895cbb4f1c71fd9470d8f9281d2bebb6d8a2
When microversioned request handling was added to placement some
comparisons were added that treat the microversions as floats. This
will break as soon as the right hand side of the version chnages
from one digit to two. A float of 1.1 and 1.10 is the same. A
version string of '1.1' and '1.10' is not.
This patch changes the internals of version handling to always use
Version objects which represent the versions using a name tuple
(major=1, minor=10). It also changes the externals to expect versions
as strings ('1.10'). Where floats were present before, these have
been changed to strings. Where tuples have been accepted, these are
still accepted, but strings are as well.
This is an internal only change, users shouldn't notice any
difference as their versions (in the openstack-api-version header)
were always strings and we haven't made it to version 1.10, sorry
'1.10', yet.
If developers try to version_handler with something other than a
version string, test runs will fail very early (at import time).
Change-Id: Ic2b655ac4c75c6104eddecd174f193413a0764d2
Closes-Bug: #1675143
Currently only HTTP 404 can be raised. This enables other HTTP status
to be raised if microversion does not match with the minimum required.
This is useful for new methods created to raise other http status code
for older placement microversions, like 405 HTTPMethodNotAllowed.
Change-Id: I2b684fcfd93fc70fe385a93346ee255279909489
Use the flake8 plugin flake8-import-order to check import ordering. It
can do it automatically and don't need reviewers to check it.
Change-Id: Ia3d81bbbb44b40804b3268c0e648276a36cb4805
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
Provide a decorator that allows Placement API handlers to
express a microversion window within which that method should be
used. This makes it possible to define N different methods (with the
same name) to present different behaviors dependent on what
microversion is requested by the user-agent.
If there is no match between a valid requested microversion and
available versioned handlers a 404 response is returned.
The mechanism for managing the versioned handlers is borrowed
from the compute api but adjusted to allow for the fact that
placement handlers are module level functions. Some code is
borrowed from twisted to get fully qualified names of methods for
the VERSION_METHODS dictionary.
Tests are added which validate that versioned handlers do not
intersect. In the rest of nova this is done at runtime, but
in the placement context this isn't necessary. Doing it at testime
is sufficient. Since there are currently no versioned handlers
in addition to the faked tests of the intersection handling I
also manually forced some tests with real handlers, just to be
sure.
Change-Id: I713c139ee12bb7f5301edd85951f8960fda84ac3
Chris Dent