New instance reservation¶

Use Cases¶

As Wei the project owner of a Telco operator, I want to specify my resource usage request for planned events. Some examples of time-based usage requests:

• I plan to use up to 60 vCPUs and 240GB of RAM from 06/01/2017 to 08/14/2017.
• I want guaranteed access to 4 instances with 1 vCPU, 1GB of RAM, and 10GB of disk. This example is similar to what would be described in the VNFD[2].

Short-term goal¶

With respect to affinity and anti-affinity rules, instance reservation only supports anti-affinity rule reservation because affinity rule reservation has already been achieved by host reservation. Affinity rule reservation by host reservation feature is not an ideal goal. For the data center usage efficiency, host reservation is not a good choice because a total amount of resources in a reservation is usually less than one hypervisor spec. It results in unused instance slots in the reserved hypervisors.

On the other hand, a hypervisor in the OpenStack cluster must accept total amount of instances in one reservation, it is equal to instance size times instance number, as affinity rule reservation. So the host reservation feature that is already implemented can handle instance reservation with affinity rule.

Prerequisites:

• The following three scheduler configuration values must be defined in nova.conf to use instance reservation:
  • AggregateInstanceExtraSpecsFilter
  • AggregateMultiTenancyIsolationFilter
  • ServerGroupAntiAffinityFilter

For the anti-affinity rule, Blazar will do the following steps:

0. As a preparation, Blazar adds filter_tenant_id=blazar-user-id to the freepool aggregate to prevent non-reservation instances from being scheduled into the freepool.

1. A tenant user creates their reservation, in Blazar terms called a “lease”, with a time frame, the instance size, and how many instances.

   One “reservation” in Blazar terms represents a tuple of <flavor, number of instances with the flavor> and one “lease” can have multiple “reservations”. Thus one lease can have multiple instance types.

2. Blazar checks whether the reservation is acceptable during the time frame or not. If acceptable, Blazar records the reservation request in its database and updates hypervisor usage in the freepool. Then Blazar returns the reservation id. If not, Blazar responds that the reservation is not acceptable and provides additional information to the tenant, e.g. the number of instances reserved is greater than the instance quota.

3. At the start time of the reservation, Blazar creates a server group, a flavor, and a host aggregate related to the reservation. Then it adds the hypervisors onto which reserved instances are scheduled to the aggregate.

   The tricks Blazar is doing here are:

   • create server group with anti-affinity policy
   • create a flavor with two extra_specs, is_public=False and flavor access rights to the user. The extra_specs are aggregate_instance_extra_specs:reservations:<reservation-id> and affinity_id:<server-group-id>
   • create a new host aggregate with above aggregate_instance_extra_specs and filter_tenant_id of the requesting user’s project id
   • does not bring out the hypervisor from the freepool because other user’s reservations also use other instance slots in the hypervisor

4. The user fetches the server_group id by calling the flavor show API in

   Nova, then creates reserved instances with a scheduling hint, like –hint group=group-id, and the newly created flavor.

Long-term goal¶

Instance reservation supports both affinity rule and anti-affinity rule.

The affinity rule reservation allows other instances or reservation to use unused instance slots in reserved hypervisors. The Nova team is developing placement API[1]. The API already has custom resource classes[2] and is now implementing a scheduler function[3] that uses custom resources classes. It enables operator to more efficiently manage hypervisors in the freepool.

Blazar will do the following steps:

1. A tenant user creates their reservation, in term of Blazar called “lease”, with a time frame, the instance size, and how many instances.
2. Blazar checks whether the reservation is acceptable during the time frame or not. If acceptable, Blazar records the reservation request in its database and updates the usage of hypervisor in freepool. Then Blazar returns the reservation id. If not, Blazar responds the reservation is not acceptable.
3. At the start time of the reservation, Blazar creates a custom resource class, a flavor, and a resource provider of the custom resource class.
4. The user creates reserved instances with the newly created flavor.

Some functionality of the placement API is under implementation. Once the development is finished, the Blazar team will start using the placement API.

Alternatives¶

This feature could be achieved on the Blazar side or on the Nova side.

Data model impact¶

A new table, called “instance_reservations”, is introduced in the Blazar database. The instance reservation feature uses the existing computehost_allocations table to store allocation information. Usage of the table is as follows:

1. In the create lease/reservation, Blazar queries hosts that are used for instance reservations or are not used by any reservations during the reservation time window.
2. If some hosts are already used for instance reservations, Blazar checks that the reserved instances could be allocated onto the hosts.
3. If some hosts are not used by any reservation, Blazar adds a mapping of the reservation to computehost as computehost_allocations table.
4. For the host reservation, the current design will never pick hosts which have a mapping, a reservation to hosts, during the reservation time window, so instance reservation does not impact host reservation queries.

The table has size of reserved flavor, vcpu, memory size in MB and disk size in GB, amount of instances created with the flavor, and an affinity flag.

CREATE TABLE instance_reservations (
    id VARCHAR(36) NOT NULL,
    reservation_id VARCHAR(255) NOT NULL,
    vcpus INT UNSIGNED NOT NULL,
    memory_mb INT UNSIGNED NOT NULL,
    disk_gb INT UNSIGNED NOT NULL,
    amount INT UNSIGNED NOT NULL,
    affinity BOOLEAN NOT NULL,
    flavor_id VARCHAR(36),
    aggregate_id INT,
    server_group_id VARCHAR(36),

    PRIMARY key (id),
    INDEX (id, reservation_id)
    FOREIGN KEY (reservation_id)
      REFERENCES reservations(id)
      ON DELETE CASCADE,
);

In the short term goal, the affinity flag only supports False since instance reservation only supports anti-affinity rule. The plugin manages multiple types of Nova resources. The mappings with each resources to column data as follows:

• In the db * reservations.resource_id is equal to instance_reservations.id
• With Nova resources
  • flavor id is equal to reservations.id
    • the extra_spec for scheduling, aggregate_instance_extra_specs, is equal to prefix+reservations.id
  • aggregate name is equal to reservations.id
    • the metadata for scheduling is equal to prefix+reservations.id
  • server_group id is recorded in extra_spec of the flavor. This id will be removed in the long term goal, as it is better encapsulated in the Nova API.

REST API impact¶

• URL: POST /v1/leases
  • Introduce new resource_type “virtual:instance” for a reservation

Request Example:

{
  "name": "instance-reservation-1",
  "reservations": [
    {
      "resource_type": "virtual:instance",
      "vcpus": 4,
      "memory_mb": 4096,
      "disk_gb": 10,
      "amount": 5,
      "affinity": false
    }
   ],
  "start": "2017-05-17 09:07"
  "end": "2017-05-17 09:10",
  "events": []
}

Response Example:

{
  "lease": {
    "reservations": [
      {
        "id": "reservation-id",
        "status": "pending",
        "lease_id": "lease-id-1",
        "resource_id": "resource_id",
        "resource_type": "virtual:instance",
        "vcpus": 4,
        "memory_mb": 4096,
        "disk_gb": 10,
        "amount": 5,
        "affinity": false,
        "created_at": "2017-05-01 10:00:00",
        "updated_at": "2017-05-01 11:00:00",
      }],
   ..snippet..
  }
}

• URL: GET /v1/leases
• URL: GET /v1/leases/{lease-id}
• URL: PUT /v1/leases/{lease-id}
• URL: DELETE /v1/leases/{lease-id}
  • The change is the same as POST /v1/leases

Security impact¶

None

Notifications impact¶

None

Other end user impact¶

python-blazarclient needs to support resource reservations of type virtual:instance in lease handling commands.

Performance Impact¶

None

Other deployer impact¶

The freepool that is used in physical:host plugin is also used by the virtual:instance plugin if the deployer activates the new plugin.

Developer impact¶

None

Assignee(s)¶

Primary assignee:

muroi-masahito

Other contributors:

None

Work Items¶

• Create the new table in blazar
• Create instance reservation plugin
• Change reservation_pool.py and nova_inventory.py to be more generic since both host_plugin and instance_plugin will use these classes
• Change BlazarFilter to pass hosts which are in instance reservation aggregates if the reservation’s extra_spec is specified.
• Add instance reservation supports in python-blazarclient
• Add scenario tests in gate job, mainly Tempest job