Difference between revisions of "ExtensibleResourceTracking"
(→Summary) |
(→Summary - (in progress)) |
||
| Line 4: | Line 4: | ||
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. | 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 | + | 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. | 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. | ||
| − | + | So we need: | |
| + | * a definition of a resource | ||
| + | * a definition of a resource requirement | ||
| + | * a means to specify resources for compute nodes | ||
| + | * a means to specify resource requirements for instances | ||
| + | * a naming scheme to allow resource requirements to be related to resources | ||
| + | * a means for the compute nodes to communicate resource availability to the scheduler | ||
| − | + | We assume we will use objects throughout | |
| − | |||
| − | + | === A definition of a resource === | |
| − | |||
| − | |||
| − | === | ||
The job of tracking the quantity of resources available on a compute node falls to the resource_tracker and the job of testing if there is sufficient capacity falls to the Claim | The job of tracking the quantity of resources available on a compute node falls to the resource_tracker and the job of testing if there is sufficient capacity falls to the Claim | ||
| − | === | + | === A definition of a resource requirement === |
| − | === | + | === A means to specify resources for compute nodes === |
| − | + | === A means to specify resource requirements for instances === | |
| + | === A naming scheme to allow resource requirements to be related to resources === | ||
| − | + | === A means for the compute nodes to communicate resource availability to the scheduler === | |
Revision as of 11:57, 28 November 2013
Contents
- 1 Summary - (in progress)
- 1.1 A definition of a resource
- 1.2 A definition of a resource requirement
- 1.3 A means to specify resources for compute nodes
- 1.4 A means to specify resource requirements for instances
- 1.5 A naming scheme to allow resource requirements to be related to resources
- 1.6 A means for the compute nodes to communicate resource availability to the scheduler
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.
So we need:
- a definition of a resource
- a definition of a resource requirement
- a means to specify resources for compute nodes
- a means to specify resource requirements for instances
- a naming scheme to allow resource requirements to be related to resources
- a means for the compute nodes to communicate resource availability to the scheduler
We assume we will use objects throughout
A definition of a resource
The job of tracking the quantity of resources available on a compute node falls to the resource_tracker and the job of testing if there is sufficient capacity falls to the Claim
