Multi Availability Zones Support¶

Use Cases¶

• An user want to reserve instances to deploy a software cluster in one az.
• An user want to reserve hosts in specific az due to the location of the az.

Alternatives¶

Data model impact¶

A availability_zone column is added to the ComputeHost table. This column stores the availability zone the host belongs to.

ALTER TABLE computehosts ADD
    availability_zone VARCHAR(255) AFTER status;

NULL is assigned to the colum for the upgrade from Pike to later.

REST API impact¶

• URL: POST /v1/leases
  • The hypervisor_properties in physical:host and the resource_properties in virtual:instance support a query for availability_zone key.

Request Example:

{
  "name": "instance-reservation-1",
  "reservations": [
    {
      "resource_type": "virtual:instance",
      "vcpus": 4,
      "memory_mb": 4096,
      "disk_gb": 10,
      "amount": 5,
      "affinity": False,
      "resource_properties": "[\"==\", \"$availability_zone\", \"az1\"]"
    },
    {
      "resource_type": "physical:host",
      "min": 3,
      "max": 4,
      "hypervisor_properties": "[]",
      "resource_properties": "[\"==\", \"$availability_zone\", \"az1\"]"
    }
   ],
  "start": "2020-05-17 09:00"
  "end": "2020-05-17 10:00",
  "events": []
}

Response Example:

{
  "leases": {
    "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,
        "resource_properties": "[\"==\", \"$availability_zone\", \"az1\"]",
        "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¶

The original az name a hypervisor belongs to is only visible through Blazar API. Nova returns az name based on meta data of host aggregate and Blazar sets blazar_* az name to an aggregate of host reservation. It results users need to call Blazar Host details API when they want to know what az value is available in “availability_zone” key.

In most cases, only admin is allowed to configure az in Nova. Admins/cloud providers/cloud deployers inform end users of list of az name. So the impact described above has less impact to end users.

Performance Impact¶

None

Other deployer impact¶

When upgrading Blazar, availability_zone column is filled by NULL. If depoloyers set the az_aware flag to True, they need to re-create all hosts registered in Blazar’s freeppol after upgrading to store availability zone information into computehost table. If hosts are used for a host reservation Blazar can’t find out the original az information while deployers upgrade Blazar.

If deployers move a host to another availability zone by Nova API, the deployers need to re-create the host by the Blazar host create API to apply the new availability zone to the Blazar DB. The information is automatically registered by Blazar only in the Blazar host create API.

Developer impact¶

None

Assignee(s)¶

Primary assignee:

muroi-masahito

Other contributors:

None

Work Items¶

• Add availability_zone column to computehosts table
• Implement availability_zone support in the create host API
• Support availability_zone flag in blazarclient