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
There are cases where ``root_provider_id`` of a resource provider is
set to NULL just after it is upgraded to the Rocky release. In such
cases getting allocation candidates raises a Keyerror.
This patch fixes that bug for cases there is no sharing or nested
providers in play.
Change-Id: I9639d852078c95de506110f24d3f35e7cf5e361e
Closes-Bug:#1799892
Later patches will introduce a field in RequestSpec using this type as
the field type to store the resource requests coming from outside of
Nova like the bandwidth request coming from the Neutron ports.
This patch refactors the usage of placement.lib.RequestGroup. Until now
this class was used both by placement and nova services and they used
it only as a util class. However after this series the nova services
would like to use such a class via RPC which requires an OVO. This
patch makes sure that the new OVO is used by nova and the old plain
object is used by placement. This way placement is not forced to use
an OVO where no OVO functionality is required.
The minimum required version of oslo.versionedobjects is updated to
1.33.3 to include the fix for bug 1771804.
Change-Id: I46c97d2641d9685ef59771314665a17a5236097d
blueprint: bandwidth-resource-provider
There are cases where ``root_provider_id`` of a resource provider is
set to NULL just after it is upgraded to the Rocky release. In such
cases getting allocation candidates raises a Keyerror.
This patch recreate that bug by simulating the situation by
inserting the records to the database directly.
Change-Id: Iaed912314f3e8fef2f46453a6bf12011702ae1dd
Related-Bug:#1799892
This patch adds a test for _get_provider_ids_matching()
to verify it works correctly with required traits.
Related-Bug: #1786519
Change-Id: I2512e361f5eaa4e60701be7c8bf57b2e0a02a146
There is now a placement.base.TestCase for placement functional tests
which assembles the necessary configuration and fixtures. This change
uses that base class in the db functional tests and extends the base
class as required to add all the necessary functionality.
In the process issues were exposed in the fixtures.gabbits use of
oslo_config (causing tests to fail based on fallout from changes
elsewhere in the functional tests) so this change also fixes that
and limits the gabbi tests to only caring about the placement database
connection, which is more correct and how it should have been all
along.
This change removes the ConfPatcher fixture in fixtures.placement
because it is no better than using the oslo_config provided
fixture and was in the way while diagnosing difficulties with
getting these changes to work correctly.
The root cause of those problems was that placement changes were
at cross purposes with how the nova.tests.fixtures.Database fixture
expects to work: The goal of these changes was to only configure
and establish those fixtures that were strictly necessary for
placement in the placements tests. However, when _any_ database
is requested from the Database fixture, the context managers for
all of them are configured.
This means, for example, that if a placement fixture, which
originally was not configuring a 'connection' string for the api
or main databases, ran before a later api db fixture, the api db
fixture would fail with no connection string available.
The quick and dirty fix is used here to fix the problem: we set
reasonable configuration for all three databases in the placement
tests that need the placement database fixture.
In the future when placement is extracted, these problems go away
so it does not seem worth the effort (at least not now) to
restructure the nova Database fixture.
blueprint: placement-extract
Change-Id: Ice89e9a25f74caaa53b7df079bd529d172354524
There are two new test cases proposed in this patch about shared RPs.
The generic setup in both cases are the following:
CN1 (VCPU, MEMORY_MB)
/ \
/agg1 \agg2
/ \
SS1 ( SS2 (
DISK_GB) IPV4_ADDRESS
SRIOV_NET_VF)
In the first case we only request resources provided by SS1 and SS2
but not CN1. In the second case we also request resources from CN1
besides requesting resources from SS1 and SS2.
The first case had been broken before nested providers are supported.
But this is fixed now thanks to the following commit, which enables
getting nested providers as well as sharing providers.
patch: https://review.openstack.org/#/c/567508/
commit: 068c56f55d
Closes-Bug: #1732731
Change-Id: Iaf7993773b8f1f5cf3cb83c161b4c88d9368297b
Co-Authored-By: Tetsuro Nakamura <nakamura.tetsuro@lab.ntt.co.jp>
Getting allocation candidates, in provider_summaries we have only
providers that are in allocation_requests.
This patch fixes it to include all the providers in trees in play.
Change-Id: I108dceb13bdefc541b272ea953acc1dec2945647
Blueprint: placement-return-all-resources
If 'connection' is set in the 'placement_database' conf group use
that as the connection URL for the placement database. Otherwise if
it is None, the default, then use the entire api_database conf group
to configure a database connection.
When placement_database.connection is not None a replica of the
structure of the API database is used, using the same migrations
used for the API database.
A placement_context_manager is added and used by the OVO objects in
nova.api.openstack.placement.objects.*. If there is no separate
placement database, this is still used, but points to the API
database.
nova.test and nova.test.fixtures are adjusted to add awareness of
the placement database.
This functionality is being provided to allow deployers to choose
between establishing a new database now or requiring a migration
later. The default is migration later. A reno is added to explain
the existence of the configuration setting.
This change returns the behavior removed by the revert in commit
39fb302fd9 but done in a more
appropriate way.
Note that with the advent of the nova-status command, which checks
to see if placement is "ready" the tests here had to be adjusted.
If we do allow a separate database the code will now check the
separate database (if configured), but nothing is done with regard
to migrating from the api to placement database or checking that.
blueprint placement-extract
Change-Id: I7e1e89cd66397883453935dcf7172d977bf82e84
Implements: blueprint optional-placement-database
Co-Authored-By: Roman Podoliaka <rpodolyaka@mirantis.com>
Removes the consumer_id, project_id and user_id fields from the
Allocation object definition. These values are now found in the Consumer
object that is embedded in the Allocation object which is now
non-nullable.
Modifies the serialization in the allocation handler to output
Allocation.consumer.project.external_id and
Allocation.consumer.user.external_id when appropriate for the
microversion.
Calls the create_incomplete_consumers() method during
AllocationList.get_all_by_consumer_id() and
AllocationList.get_all_by_resource_provider() to online-migrate missing
consumer records.
Change-Id: Icae5038190ab8c7bbdb38d54ae909fcbf9048912
blueprint: add-consumer-generation
The response of ``GET /allocation_candidates`` API provides two fields
of ``allocation_requests`` and ``provider_summaries``. The callers,
like the filter scheduler in nova, would use information in
``provider_summaries`` in sorting or filtering providers to allocate
consumers. However, currently ``provider_summaries`` doesn't contain
resource classes that aren't requested.
With this patch, ``GET /allocation_candidates`` API returns all
resource classes with a new microversion.
Change-Id: Ic491f190ebd97d94c18931a0e78d779a55ee47a1
Closes-Bug: #1760276
Blueprint: placement-return-all-resources
Getting allocation candidates, placement calls _get_trees_matching_all
to get all trees that satisfy user requests. The function consisted of
two phases, checking the amount of inventory and checking traits.
This patch extracts checking traits phase into separated function,
_get_trees_with_traits and creates tests specialized to trait check.
This patch also changes the SQL logic to use different join tables
for required and forbidden traits to make it more efficient according
to the comment in [1].
[1] https://review.openstack.org/#/c/567113/14/nova/api/openstack/placement/objects/resource_provider.py@3346
Change-Id: Ief8d982899d4203d79fb4b5117340d92b9d3a94e
Blueprint: nested-resource-providers-allocation-candidate
Co-Authored-By: Jay Pipes <jaypipes@gmail.com>
In tests getting allocation candidates, this patch deletes
duplicate function of _get_rp_ids_matching_names() and use
_get_rp_ids_matching_names() instead.
Change-Id: I5b74cf1af3d03d346d40c6cf0f19b8d51439d878
There can be legitimately distinct allocation requests with the same
combination of providers. For example, in a case where where both
SHR1 and SHR2 have both CUSTOM_RC1 and CUSTOM_RC2, the following two
allocation requests are different:
AllocationRequest(anchor=CN, resource_requests=[
AllocationRequestResource(rp=CN, resources=[VCPU: 1]),
AllocationRequestResource(rp=SHR1, resources=[CUSTOM_RC1: 1]),
AllocationRequestResource(rp=SHR2, resources=[CUSTOM_RC2: 1]),
])
AllocationRequest(anchor=CN, resource_requests=[
AllocationRequestResource(rp=CN, resources=[VCPU: 1]),
AllocationRequestResource(rp=SHR2, resources=[CUSTOM_RC1: 1]),
AllocationRequestResource(rp=SHR1, resources=[CUSTOM_RC2: 1]),
])
But getting allocation candidates, placement had been filtering out
one of the two assuming them as the same allocation requests because
the combination of the providers in play was the same.
This was because placement filtered duplicate candidates using a set
of provider ids in play while we can't consider resource information
with the set. This patch fixes the bug by using the list instead of
the set. This is because we can put resource information in the order
of that list. Namely, in the example above, we can't detect
"set([CN, SHR1, SHR2])" is different as "set([CN, SHR2, SHR1])", but
we can detect [CN, SHR1, SHR2] is different from [CN, SHR2, SHR1].
Change-Id: I90627dfe85661118c4ec2571fc32ffca99dd73d2
Blueprint: nested-resource-providers-allocation-candidates
Closes-Bug: #1772243
This patch enables nested allocation candidates in cases where
sharing providers are also in the environment.
The logic is mainly added to the existing function
_alloc_candidates_nested_no_shared() renaming it to
_alloc_candidates_multiple_provider().
Because this new function is also available when there is neither
sharing providers nor nested providers, this patch merges the
existing _alloc_candidates_with_shared() and _get_all_with_shared()
function to _alloc_candidates_multiple_provider().
Change-Id: Ib1738fb4a4664aa7b78398655fd23159a54f5f69
Blueprint: nested-resource-providers-allocation-candidates
This patch adds trait check in the path used in getting allocation
candidates with nested providers creating a trait check helper
function, _check_traits_for_alloc_request().
Change-Id: I728825a03db9f6419c8f4b3fa23aef63ec8baa5e
Blueprint: nested-resource-providers-allocation-candidates
Closes-Bug: #1771707
This patch start to return nested providers in get_by_requests().
However, this is not complete because
1) It leaves a bug that placement returns a "branch" without requested
traits in a "tree", one of whose "branch" has requested traits.
This is reported in bug#1771707.
2) Not all the resource providers in a tree are returned
in provider_summaries. This is done later under the
blueprint: placement-return-all-resources.
3) It doesn't support cases where there are sharing providers in the
system.
These are well described in test cases and will be addressed in
following patches.
Blueprint: nested-resource-providers-allocation-candidates
Change-Id: Ib119a7e14d83a3562519b4653fb0813f2d31af21
Related-Bug: #1771707
There was a test to validate we get all the possible combinations
of sharing providers if they have the requested resources.
However, this test validates the case where one sharing provider
has single shared resource class. This patch expand the test case
to validate that we still get all the possible combinations for
the case where all the sharing providers have multiple shared
resource classes.
Change-Id: I89a970362cbfdd25840901f4635a9e0bffb2c94f
Related-Bug: #1772243
Now _get_trees_matching_all() function returns a list of two-tuples,
(provider internal ID, root provider internal ID). However its unit
test validates only the second values, root provider ids, of the
tuples.
This patch expands existing test function, test_trees_matching_all(),
to test the first values, provider ids, in the tuples as well.
Change-Id: I3dd44088230303bf6754d80e63d21e0315bd3336
Blueprint: nested-resource-providers-allocation-candidates
Related-Bug: #1771707
Now we support multiple member_of query in placement regardless of
whether sharing providers are in the environment or not.
However, the functional test is only for the cases where non-sharing
providers don't have the same resources with sharing providers.
This patch expands the existing test cases showing that we still
include allocation requests where the resource is provided by the
non-sharing providers when they have the same resources with sharing
providers.
Change-Id: Ide2272513c2f550e4539f2c94b581a82426f65f3
Blueprint: alloc-candidates-member-of
When the `member_of` parameter was present, non-sharing providers
incorrectly associated sharing providers with other sharing providers
with no direct connection to non-sharing providers involved in other
parts of the request.
This patch fixes the bug by adding the aggregate check in SQL
query when getting sharing providers.
Change-Id: I566cc5458175f8e3075be6967e5f6d91847ce198
Closes-Bug: #1763907
Blueprint: alloc-candidates-member-of
This patch add a functional test which describes a bug that when
the `member_of` parameter is present, only non-sharing providers
in the specified aggregates are picked, but the non-sharing
provider brings sharing providers from out of the specified
aggregates.
Change-Id: Ie098bb6fa21b3656a8ea840f4e6d9407311bddcd
Related-Bug: #1763907
Blueprint: alloc-candidates-member-of
This patch deletes a duplicative test and enhance it to validate a
case where a compute node's local disk is not enough while there
is a shared storage with enough disk.
This case has been already fixed thanks to new _exceeds_capacity
function from commit 9af073384c.
Change-Id: Ia544dc529c844f7bee5b04f90456fd66a20ecdd0
Related-Bug: #1769854
In a new microversion, the GET /allocation_candidates API now accepts
granular resource request syntax:
?resourcesN=...&requiredN=...&member_ofN=...&group_policy={isolate|none}
Change-Id: I4e99974443aa513fd9f837a6057f67d744caf1b4
blueprint: granular-resource-requests
The preceding patch brought in symbols from the test_base module to
minimize the delta. This patch removes these, renames the private ones
to be public, and changes all their usages to reference them from
test_base directly.
Change-Id: I43b7cfe9dbcb6de607f0c166b065a1ec3543c256
Initial change set factoring a common base test class and helper
utilities out of test_resource_provider and test_allocation_candidates.
This one minimizes the delta by copying some module-level symbols into
the test suites. Subsequent patches will refactor to avoid this, clean
up naming (so we're not accessing privates from another module), and use
the now-common utility methods in more places.
Change-Id: Ibd38a3903a2d347a4ff4702d0d1172f6e37e7d19
Reworks the way that we solve requests for resource when nested resource
providers are present. When a granular request group is *not* sent, we
ensure that each separate resource class in the request is met by a
single provider (not summing inventories across the tree). For each
separate resource class in the request, we make a separate query to
determine the provider and root provider IDs of those resource providers
which can satisfy that request for a particular resource.
We then filter out providers that are in trees that did *not* have all
resources met by some provider in the tree. After that, we further
filter for the providers that are in trees that contain all required
traits and that the provider of those traits were the providers giving
inventory to the request.
Co-Authored-By: Balazs Gibizer <balazs.gibizer@ericsson.com>
Change-Id: I343a0cb19f4037ddde5c5fc96d0a053f699f5257
blueprint: nested-resource-providers-allocation-candidates
Adds functional tests for the AllocationCandidates.get_by_filters()
function that includes a required trait in addition to resource amounts
and the deployment has nested resource providers.
The functionality is yet to be implemented, so the test asserts
currently incorrect behaviour but is well-commented so reviewers should
be able to figure out what the scenario we're trying to isolate is.
Change-Id: Id1463f2e6fbb80eea9241dd1f6e22b6b99c4ee54
blueprint: nested-resource-providers-allocation-candidates
Adjust the generated SQL and surrounding python code to support
expressing forbidden traits when requesting allocation candidates.
Any resource provider which has a forbidden trait will not be
included.
The RequestGroup object now supports a forbidden_traits attribute.
Code in forthcoming patches will adjust the query string processing
that creates a RequestGroup to set that attribute if the calling code
is using the right microversion.
Partially implements blueprint placement-forbidden-traits
Change-Id: I53f6fce0810c53551710407df7ab1689282e73f3
In `test_allocation_candidates.py`, there are some tests that
validate `allocation_requests` without checking `provider_summaries`.
This patch complements the tests by adding to the test functions
`_validate_provider_summary_resources`, a base test to check
what is in `provider_summaries`.
This change will help us build new features such as nested and
shared providers without breaking the existing behavior.
Change-Id: Ifa7a21a1f83f4a23747d1c6316d9bffcf158ff9a
In ``GET /allocation_candidates`` API, ``provider_summaries``
should show all the inventories for all the resource classes
in all the resource providers.
However, ``provider_summaries`` currently doesn't contain
resources that aren't requested.
This patch adds a simple test case to describe the bug.
Change-Id: Ida9cddc5a2b43917e7b5900fe68a413b18c6cb2d
Partial-Bug: #1760276
Placement functional tests could, depending on run order, be unable
to synchronise the os-traits because a previous test or this test
has failed to reset the _TRAITS_SYNCED flag.
This change fixes it so the tests will always reset the flag at
both setUp and tearDown.
In the process a nearby misleading comment which says a database is
not being used is corrected.
Change-Id: I595be7bca2c1bde86651b126ce501286b301d272
Closes-Bug: #1759863
When both the compute node resource provider and the shared
resource provider have inventory in the same resource class,
AllocationCandidates.get_by_filters didn't return an
AllocationRequest including the shared resource provider.
To fix the bug, this patch changes the function of
_alloc_candidates_with_shared() to consider resources from
non-sharing providers and resources from sharing providers
at the same time.
Change-Id: Iaf23f35f2f9a5d27a814ef5b94abed1a8b365bc3
Closes-Bug: #1724613
Related-Bug: #1731072
A set of placement functional test is in db layer and we plan to move
placement out of nova, better to move this file to
functional/api/openstack/placement
partial implement blueprint placement-extract
Change-Id: Ie25ed974a19d8fe7bc367e2e0593646a620a49e9
Chris Dent