Files

Balazs Gibizer f20e13f0b2 Add round-robin candidate generation strategy

The previous patch introduced [placement]max_allocation_candidates
config option to limit the number of candidates generated for a single
query.

If the number of generated allocation candidates are limited by that
config option then it is possible to get candidates from a limited set of
root providers (computes, anchoring providers) as placement uses a
depth-first strategy, generating all candidates from the first root
before considering the next one.

To avoid unbalanced results this patch introduces a new config option
[placement]allocation_candidates_generation_strategy with the possible
values:
* depth-first, the original strategy that generates all candidate from
  the first root before moving to the next. This is will be the default
  strategy for backward compatibility
* breadth-first, a new possible strategy that generates candidates from
  available roots in a round-robin fashion, one candidate from each
  root before taking the second candidate from the first root.

Closes-Bug: #2070257
Change-Id: Ib7a140374bc91cc9ab597d0923b0623f618ec32c

2025-01-09 09:29:07 +01:00

functional

Add round-robin candidate generation strategy

2025-01-09 09:29:07 +01:00

unit

Add round-robin candidate generation strategy

2025-01-09 09:29:07 +01:00

__init__.py

Rename the 'nova' directories to 'placement'

2018-09-04 10:31:22 -05:00

fixtures.py

Stop to use the __future__ module.

2020-06-03 10:38:03 +02:00

README.rst

Link to tempest doc in tests/README.rst

2018-09-14 09:32:27 -06:00

README.rst

OpenStack Placement Testing Infrastructure

This README file attempts to provides some brief guidance for writing tests when fixing bugs or adding features to placement.

For a lot more information see the contributor docs.

Test Types: Unit vs. Functional vs. Integration

Placement tests are divided into three types:

Unit: tests which confirm the behavior of individual pieces of the code (individual methods or classes) with minimal dependency on other code or on externals like the database.
Functional: tests which confirm a chunk of behavior, end to end, such as an HTTP endpoint accepting a body from a request and returning the expected response but without reliance on code or services that are external to placement.
Integration: tests that confirm that things work with other services, such as nova.

Placement uses all three, but the majority are functional tests. This is the result of the fairly direct architecture of placement: It is a WSGI application that talks to a database.

Writing Unit Tests

Placement unit tests are based on the TestCase that comes with the testtools package. Use mocks only as necessary. If you find that you need multiple mocks to make a test for the code you are testing may benefit from being refactored to smaller units.

Writing Functional Tests

There are two primary classes of functional test in placement:

Testing database operations. These are based on placement.tests.functional.base.TestCase which is responsible for starting an in-memory database and a reasonable minimal configuration.
Testing the HTTP API using gabbi.

Writing Integration Tests

Placement configures its gate and check jobs via the .zuul.yaml file in the root of the code repository. Some of the entries in that file configure integration jobs, many of which use tempest.