Resource providers are a new vision for how to track consumable resources in Nova. These are things like compute nodes, which host VMs, and shared disk. The information is used, for just one example, during scheduling of servers: Do we have the resources to place this server? Who has those resources?
Several specs encapsulate the plans:
Summaries
Resource classes provide a collection of types (classes!) of resource that are available in the system and a lookup table to be used by providers of resources of that type. This makes it possible to keep resource information of many different types in the same table and add new classes of resource without changing database schema. Work on this has started at these reviews.
A resource provider is an instance of something that provides resources (of one or more classes). The resource provider spec describes creating three data models (and corresponding versioned objects): resource_providers, inventories, allocations. resource_providers maps a local id to the uuid of a "real" resource in the OpenStack universe. inventories provides the baseline information of how much of a resource the provider provides and the granularity at which it can provide (the min and max units per provision). allocations records when a consumer has claimed some volume of inventory from a provider. Together these keep track of what's available and what's been used.
A resource pool is for keeping track of resource provided by something that is not on a compute node, for example shared disk. Historically these have been tracked as if they were from a compute node, leading to inaccurate measurments of available resources and poor tracking of usage. A resource pool will be exposed in the API: they can be created and updated and have their capacity regularly updated (by the entity represented by the resource pool).
Migrating compute node inventory involves creating resource providers and inventories for the information that has been stored in compute_nodes. As a migration of that information would be against minimal downtime upgrades it needs to be possible to migrate the data as it is used. In order for compute nodes to be represented in the resource providers table they need to gain a uuid. Each compute node needs to be added to resource providers. Inventory then needs to be updated for each class of resource that a compute node provides (vcpus, ram, etc). These changes can be transparent by building them into the ComputeNode object. When it can't find resource information in the new way, it looks in the old way.
Getting it Done
Specs 2, 3 and 4 are dependent on spec 1 (in progress). 3 and 4 are dependent on 2 but are independent of one another. All four specs provide pretty good overviews of the actual tasks that are required to get them done. Some can be broken into dependent pieces. For example the creation of data models in 2 and 3 can be separated (to some extent) from the work to create objects. And the API creation in 3 can be separated from the rest.
Updates
jay has produced the rest of the specs:
- resource-classes: https://review.openstack.org/256297
- resource-providers: https://review.openstack.org/225546
- generic-resource-pools: https://review.openstack.org/253187
- compute-node-inventory: https://review.openstack.org/260048
- resource-providers-allocations: https://review.openstack.org/271779
- resource-providers-scheduler: https://review.openstack.org/271823
- pci-generate-stats: https://review.openstack.org/#/c/240852/