Commit Graph

5 Commits

Author SHA1 Message Date
Chris Dent 787bb33606 Use external placement in functional tests
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
2018-12-12 18:46:49 +00:00
Jay Pipes 4b62b6bfc9 make incomplete_consumer_project_id a valid UUID
Unfortunately, when I added the CONF.incomplete_consumer_project_id and
CONF.incomplete_consumer_user_id options, the default value for those
options was an invalid UUID (it had 13 zeroes for the last part of the
UUID instead of 12). This is preventing some work that tries to disable
warnings about invalid UUIDs being stored in ovo UUIDField objects.

The work to "heal allocations" will be able to fix up any deployments
that deployed the invalid UUID default CONF value because it looks for
any instances in Nova where the placement allocation records don't have
a matching user/project and replaces the mismatched user/project IDs on
the consumer appropriately.

Change-Id: I67b3b771f20e0b83225fce4839d378696fe1ab24
Closes-bug: #1780107
2018-07-09 19:15:46 +01:00
Balazs Gibizer 9012a09328 Use valid UUID in the placement gabbits
It seems gabbi does not resolve yaml refs in the URL part of a REST
call. This causes that the tests in ensure-consumer.yaml uses invalid
consumer id '*consumer_id'

This patches replace the *consumer_id with a fixture ref that works.

Change-Id: I0576f282b1801340db6827fb4c9520a0d48ad7f0
Related-Bug: #1780238
2018-07-05 14:09:04 +02:00
Matt Riedemann aca9b9243a Fix nits from change Id609789ef6b4a4c745550cde80dd49cabe03869a
Change-Id: Ia321b2e33c11595db83221698b2c98b9b991ba48
2018-06-20 12:11:09 +01:00
Jay Pipes 03d80cf0de placement: always create consumer records
Adds objects for Consumer, Project, and User data models, in their own
files. They do not contain logic that comes from the API microversions
and are meant to be plain-old-data objects that represent the current
schema in the database. Project, user and consumer information all are
stored in separate tables in the DB and represent actual things in the
placement data modeling. Giving them actual objects makes that
consistent with the other objects in the data model, including resource
providers, allocations, inventories, resource classes and traits.

The patch modifies the allocation handler to always ensure that a
consumer record exists for the supplied consumer UUID and an associated
projects and users table record exists for that consumer. If an
allocation is created using API microversion <1.8, which doesn't supply
the project or user for the consumer, we use the value of two new CONF
options that indicate the project and user ID for incomplete consumer
records.

Includes an online data migration for the nova-manage
online_data_migrations command that creates consumer records for
incomplete consumers.

Change-Id: Id609789ef6b4a4c745550cde80dd49cabe03869a
2018-06-11 12:45:41 -04:00