https://blueprints.launchpad.net/blazar/+spec/placement-api
Placement API [1] was introduced to Nova at the 14.0.0 Newton release to separate API and data model for tracking resource provider inventories and usages. It can be used for improving instance reservation.
Current instance reservation has the following constraints:
Use the custom resource class to represent reservation resources and use the nested resource provider to manage capacity and usage of reservation resources. The following sections describe how Blazar interacts with Nova and Placement for supporting instance reservation.
Get hypervisor information and store it into the computehosts table.
Create a nested resource provider as a child of the compute node
resource provider by calling the Create resource provider API. The UUID
of the compute node resource provider can be retrieved by calling the List
resource providers API with the name option query,
e.g. GET /placement/resource_proiders?name=compute-1
.
The child resource provider is referred to as ‘reservation provider’ in the following sections.
Create reservation provider request body example:
POST /placement/resource_providers
{
"name": "blazar_compute-1",
"parent_provider_uuid": "542df8ed-9be2-49b9-b4db-6d3183ff8ec8"
}
Note
“542df8ed-9be2-49b9-b4db-6d3183ff8ec8” is the UUID of the “compute-1” compute node.
Look for available resources with arbitrary affinity policy.
Update the computehost_allocations table.
Create a custom resource class CUSTOM_RESERVATION_{reservation UUID} by calling the Create resource class API.
Create resource class request body example:
POST /placement/resource_classes
{
"name": "CUSTOM_RESERVATION_4D17D41A_830D_47B2_91C7_4F9FC0AE611E"
}
Note
Use upper case and under score for the custom resource class name because lower case and hyphen cannot be used.
resources:CUSTOM_RESERVATION_{reservation UUID}=1
in its extra_spec.Note
Add the custom resource class CUSTOM_RESERVATION_{reservation UUID} into the reservation provider’s inventory by calling the Update resource provider inventories API with the total parameter which equals to the amount of instances reserved for the host.
Update resource provider inventories request body example:
PUT /placement/resource_providers/{reservation_provider_uuid}/inventories
{
"inventories": {
"CUSTOM_RESERVATION_4D17D41A_830D_47B2_91C7_4F9FC0AE611E": {
"total": 3,
"allocation_ratio": 1.0,
"min_unit": 1,
"max_unit": 1,
"step_size": 1
},
"snip"
},
"resource_provider_generation": 5
}
Note
Existing hosts which were created before this spec is implemented do not have the reservation provider. So, check if the reservation provider exists and create it if it does not exist before this step.
Note
The previous implementation of starting lease should be kept until the previous instance reservation is deprecated and completely removed. The previous instance reservations can be distinguished by checking the aggregate_id or server_group_id column in the instance_reservations table.
A lease owner uses the private flavor and the instance is launched on the reserved host which has the CUSTOM_RESERVATION_{reservation UUID} in it’s child resource provider inventory, i.e. reservation provider inventory.
Consumption of CUSTOM_RESERVATION_{reservation UUID} resources in the reservation provider inventory is claimed by the Nova scheduler. It means that usage of reserved resources is automatically tracked by the Placement.
Note
It still depends on the BlazarFilter though the BlazarFilter will be
ideally removed in the future. The BlazarFilter is changed to check if
resources:CUSTOM_RESERVATION_*
is in flavor extra specs to distinguish
the request from normal, i.e. non-reserved, instance creation requests.
Traits or other features would be able to be used for solving BlazarFilter dependency. It would be addressed by another blueprint.
On the other hand, dependency on the following filters are solved. These filters are not needed any more.
Note that above filters and existing logic in the BlazarFilter should be kept to keep backward compatibility until the previous instance reservation is deprecated and completely removed.
Note
The previous implementation of terminating lease should be kept until the previous instance reservation is deprecated and completely removed. The previous instance reservations can be distinguished by checking the aggregate_id or server_group_id column in the instance_reservations table.
Update inventories of the general resources, e.g. VCPU, of compute nodes in the freepool to be zero or reserved. And add dummy resources like CUSTOM_VCPU_{reservation UUID} into the inventory. This approach complicates resource usage tracking because real usage of each general resource cannot be seen through the top level compute node inventory.
The affinity column of the instance_reservations table is changed to allow
NULL
. NULL
means no affinity policy is applied
while True
means
affinity is applied
and False
means anti-affinity is applied
.
The instance_reservations table:
ALTER TABLE instance_reservations
ALTER COLUMN affinity NULL;
After the previous instance reservation is deprecated and completely removed, drop the following columns in the instance_reservations table:
ALTER TABLE instance_reservations
DROP COLUMN aggregate_id, server_group_id;
The affinity parameter of the Create lease API is changed to be an optional parameter. If the affinity parameter is not given, no affinity policy is applied.
None
None
None
None
None
Base:
To support the host creation:
To support the host deletion:
To support the lease creation:
To support starting the lease:
To support launching reserved instances:
To support termination of the lease:
Others:
WIP: Check Placement API development status.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.