ExtensibleResourceTracking
Summary - (in progress)
There are a number of defined resources in Nova, including disk, memory and number of vCPU. The purpose of this specification is to support an extensible set of resources so that new resources can be defined for compute nodes and resource requirements for instances. These will be made available to the scheduler and allocated by the compute manager.
The resources of a compute node have limited capacity. Most, including disk, memory and vCPU, map to a physical counterpart, typically via a virtualisation technology, but it is also possible to create entirely abstract resource types that do not. As an example, a provider may chose that only one instances of a certain type should run on any compute node. This trivial example can be supported by defining a new resource for compute nodes and associating a requirement for that resource with the instance type.
Each instance has resource requirements specified as the quantity of each type of resource it needs. These are used by the scheduler to match it to compute nodes with sufficient available resources.
The compute manager on a host is aware of the resources available at the compute node and is responsible for their allocation and management. Because it has definitive knowledge of what resources are actually in use, the compute manager has the final say as to whether a compute node is able to host an instance.
We will need:
- a model of a resource
- a model of a resource requirement
- a naming scheme to allow resource requirements to be related to resources
- changes for compute nodes
- resource configuration - to define extended resources
- resource_tracker - to track extended resources
- claims - to test requirements against available extended resources
- changes for instances
- resource requirements in flavors
- resource requirements in requests
- resource requirements in instances
- changes for the database
- extended resources at compute_nodes
- extended resource requirements in instances
- changes for scheduler (filter scheduler)
- host manager - to access extended resources
- filters - examples using extended resources
- weighers - examples using extended resources
Resource Models and Naming
Resource Model
A *resource* has the following attributes:
- name - used to identify this resource
- type - a resource type name for human viewing
- units - a resource unit name for human viewing
- description - a short description for human viewing
Each resource at a compute node is represented by its total amount and the amount used - this is recorded by the resource tracker and used in scheduling and allocation decisions. This information is held at the resource tracker and passed via the database to the host_manager at the scheduler.
Resource *capacity:*
- resource total = value (configured or discovered - total amount of resource)
- resource used = value (tracked - amount of resource currently used)
Each resource required for a particular instance is represented by a single value. This information is defined for a flavor, passed in create requests to be used at the scheduler and the resource_tracker/claims at a compute manager, and is inherited by an instance.
Resource *requirement*:
- resource required = value (configured - amount required)
The two final quantities associated with resources are the commit ratio and the limit. The commit ratio defines how much of a resource can be allocated (a provider may chose to over commit a resource or leave some headroom) and a limit (the total amount that can be committed. This commit ratio is configured for the scheduler and used in filters. The limit is calculated per compute node at the scheduler according to a function of other attributes. The limit is communicated with a create request and used by the resource_tracker claims.
- resource commit ratio = value (configured - a proportion of the available resource that can be allocated)
- resource limit = value (calculated - the total amount of resource that can be allocated)
In all cases a resource is known by its name and this is used to perform comparisons between information from different sources at the scheduler and the resource tracker. In some cases (such as flavors, where extra specs will be used to hold the information) a prefix is required. In this case the name "resource" will be used for individual resources and the name "resources" for lists of resources.
