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
We have two kinds of generation conflicts that happen (for both
resource providers and consumers). In
I5a164a0ee298846231113ad7b62b82a3e8f1f409 error codes are added for
conflicts that happen when incrementing the generation in the database.s
In this change the codes are added for those situations where in code we
are checking an incoming generation against the stored generation.
Since there are incoming genearations in this case, we can add tests
so this does, via gabbi.
Change-Id: I5ed005068c1c19194ed67556376604ae90727412
When we fail to create allocations for new consumers (either when
issuing a PUT /allocations/{new_consumer_uuid} or a POST /allocations
where the payload includes a new consumer UUID), we need to ensure that
we delete the Consumer object and underlying record in the consumers
table that gets auto-created before calling AllocationList.create_all().
This auto-created consumer record is what is used to compare things like
consumer generation in later calls to PUT|POST /allocations, and this
phantom consumer record was causing confusion when normal retries (for
things like 409 Conflict due to concurrent provider or inventory
updates) would be rejected stating that the expected consumer generation
was 0 and not null (null being the sentinel that indicates the caller is
expecting the consumer is a new consumer).
Change-Id: If37ef318bd5482a2d19928002c6f1fa24932946f
Closes-bug: #1779725
Closes-bug: #1778576
When PUTting allocations to a non-existent consumer, the code
expects the consumer generation to be 'null'. When there is only
one resource provider in the set of allocations sent, this works
well.
Unfortunately when there is more than one resource provider the
loop which calls _new_allocations still uses the 'null' generation
but now the code expects the generation to be 0, because the
consumer now exists.
This patch provides a gabbi test that demonstrates the problem
by creating a shared disk resource provider and associating it
as an aggregate with the existing RP_UUID. A GET
/allocation_candidates is made and a single allocation_request is
returned including both resource providers. A test with a new
consumer is marked as an xfail.
In the next patch the problem will be fixed.
Change-Id: I1238f82dfc46fd9dae126abfd16ce3dd1506e991
Related-Bug: #1778576
The placement API had a message complaining that it was "expecting None"
which is python-speak when it should be JSON speak. This change
corrects the message and adds a gabbi test for it.
Change-Id: Ibfb3d581588c8eb954a9faca19d9cb26d2c28861
Closes-Bug: #1778071
This patch adds new placement API microversion for handling consumer
generations.
Change-Id: I978fdea51f2d6c2572498ef80640c92ab38afe65
Co-Authored-By: Ed Leafe <ed@leafe.com>
Blueprint: add-consumer-generation
Chris Dent