[placement] gabbi tests for shared custom resource class

The change adds a gabbi test to cover the case where one of the resources
comes from shared resource provider that uses a custom resource class.
There had been a bug in the SQL that caused this to be incorrect, it is
now fixed. This simply adds some additional tests to confirm things are
working as desired. See the related bug for more information.

The behavior with the same query on /allocation_candidates and
/resource_providers is intentionally different, as described in the
comments on the last two tests.

Change-Id: Ic42f0cd74665574129d36eeaa093f3f316879592
Related-Bug: #1705231
This commit is contained in:
Chris Dent 2017-07-19 14:38:31 +01:00
parent cfff910b0d
commit 9984b91dc1
1 changed files with 139 additions and 0 deletions

View File

@ -0,0 +1,139 @@
# Create a shared resource provider that shares a custom resource
# class with a compute node and confim that it is returned when
# requesting resources.
#
# NOTE(cdent): raw uuids are used here instead of environment variables as
# there's no need to query on them or change them, but something has to be
# there.
fixtures:
- APIFixture
defaults:
request_headers:
x-auth-token: admin
content-type: application/json
accept: application/json
OpenStack-API-Version: placement latest
tests:
- name: create compute node 1
POST: /resource_providers
data:
name: cn1
uuid: 8d830468-6395-46b0-b56a-f934a1d60bbe
status: 201
- name: cn1 inventory
PUT: /resource_providers/8d830468-6395-46b0-b56a-f934a1d60bbe/inventories
data:
resource_provider_generation: 0
inventories:
VCPU:
total: 20
MEMORY_MB:
total: 100000
status: 200
- name: create compute node 2
POST: /resource_providers
data:
name: cn2
uuid: ed6ea55d-01ce-4e11-ba97-13a4e5540b3e
status: 201
- name: cn2 inventory
PUT: /resource_providers/ed6ea55d-01ce-4e11-ba97-13a4e5540b3e/inventories
data:
resource_provider_generation: 0
inventories:
VCPU:
total: 20
MEMORY_MB:
total: 100000
DISK_GB:
total: 100000
status: 200
- name: create custom magic
PUT: /resource_classes/CUSTOM_MAGIC
status: 201
- name: create shared 1
POST: /resource_providers
data:
uuid: d450bd39-3b01-4355-9ea1-594f96594cf1
name: custom magic share
status: 201
- name: shared 1 inventory
PUT: /resource_providers/d450bd39-3b01-4355-9ea1-594f96594cf1/inventories
data:
resource_provider_generation: 0
inventories:
CUSTOM_MAGIC:
total: 5
status: 200
# no aggregate association
- name: get resources no agg
GET: /resource_providers?resources=VCPU:1,CUSTOM_MAGIC:1
response_json_paths:
$.resource_providers.`len`: 0
- name: get allocation candidates no agg
desc: this sometimes fails
GET: /allocation_candidates?resources=VCPU:1,CUSTOM_MAGIC:1
response_json_paths:
$.allocation_requests.`len`: 0
$.provider_summaries.`len`: 0
- name: aggregate shared
PUT: /resource_providers/d450bd39-3b01-4355-9ea1-594f96594cf1/aggregates
data:
- f3dc0f36-97d4-4daf-be0c-d71466da9c85
- name: aggregate cn1
PUT: /resource_providers/8d830468-6395-46b0-b56a-f934a1d60bbe/aggregates
data:
- f3dc0f36-97d4-4daf-be0c-d71466da9c85
# no shared trait
- name: get resources no shared
GET: /resource_providers?resources=VCPU:1,CUSTOM_MAGIC:1
response_json_paths:
$.resource_providers.`len`: 0
- name: get allocation candidates no shared
GET: /allocation_candidates?resources=VCPU:1,CUSTOM_MAGIC:1
response_json_paths:
$.allocation_requests.`len`: 0
$.provider_summaries.`len`: 0
- name: set trait shared
PUT: /resource_providers/d450bd39-3b01-4355-9ea1-594f96594cf1/traits
data:
resource_provider_generation: 1
traits:
- MISC_SHARES_VIA_AGGREGATE
# this should be zero because we only expect those resource providers which
# can fully satisfy the resources query themselves when making requests of
# /resource_providers. This may change in the future depending on use
# cases. This test and the next demonstrate and confirm that
# /resource_providers and /allocation_candidates have different behaviors.
- name: get resources shared
GET: /resource_providers?resources=VCPU:1,CUSTOM_MAGIC:1
response_json_paths:
$.resource_providers.`len`: 0
# this is one allocation request and two resource providers because
# at /allocation_candiates we expect those resource providers which
# can either fully the resources query or can do so with the
# assistance of a sharing provider.
- name: get allocation candidates shared
GET: /allocation_candidates?resources=VCPU:1,CUSTOM_MAGIC:1
response_json_paths:
$.allocation_requests.`len`: 1
$.provider_summaries.`len`: 2