Make Resource Tracker Use Objects¶
https://blueprints.launchpad.net/nova/+spec/make-resource-tracker-use-objects
This blueprint was approved for Juno but missed feature freeze.
Nova is converting data structures it uses to communicate via RPC and through the database to use an object encapsulation called Nova Objects. This supports of multi-versioning for live-upgrade and database schema independence. This blueprint covers the conversion of the resource tracker to use Nova Objects.
Problem description¶
Conversion to Nova Objects will replace dict data structures that are currently communicated via the conductor API with Nova Object versions. Where necessary the Nova Objects will be extended to cover parameters that are not already implemented.
Use Cases¶
As an operator I want to be able to upgrade Nova without any downtime.
Project Priority¶
This blueprint fits under the Live Upgrades priority.
Proposed change¶
The Nova Object classes that will be used include:
ComputeNode
Instance
Migrations
Flavor
Service
The ComputeNode object is currently missing some parameters that exist in the compute_nodes table and are used in the resource tracker. The following parameters will be added to the ComputeNode:
pci_stats
In addition, the following fields exist in the compute_nodes table but are not currently used by the resource tracker. We propose not to add fields to the ComputeNode object unless they are used, so these fields will not be added as part of this blueprint.
extra_resources
When complete there will be no direct calls to conductor in the resource tracker.
Alternatives¶
There is another effort to split the scheduler from Nova. When the split is complete the resource tracker may no longer interact with the scheduler via the database. Initially, the scheduler-lib blueprint (see references) will make all compute node interaction with the scheduler go through a new scheduler library in preparation for the split.
This suggests that it might be unnecessary to use the ComputeNode object at least. However, it is reasonable to continue using the ComputeNode object even if it is not used to persist data in the database, so we will go ahead with the existing plan to implement it.
Data model impact¶
The objects isolate the code from the database schema. They are written to operate with existing data model versions. At present the scheduler does not the ComputeNode object, so code there will need to tolerate changes in database schema or the format of data stored in fields.
The fields that need to be added to the ComputeNode object are as follows:
pci_stats
Database field type: text
Object field type: fields.ObjectField(‘PciDeviceList’, nullable=True)
The pci_stats field is currently populated with a PciDeviceList serialized as an object primitive. This is already the correct form for an object field.
REST API impact¶
None.
Security impact¶
None.
Notifications impact¶
None.
Other end user impact¶
None.
Performance Impact¶
None.
Other deployer impact¶
The objects are written to be compatible with the database schema used in Juno. There is no database migration associated with this blueprint and the format of data stored in the fields of the database will not change. This means that a combination of Juno and Kilo versions of the compute nodes will be able to coexist and interact with the scheduler.
Developer impact¶
Developers working on the resource tracker will be required to use the new objects instead of directly making database calls to conductor.
Implementation¶
Assignee(s)¶
- Primary assignee:
pmurray
Work Items¶
Use flavor object in resource tracker
Use Service object in resource tracker
Use Instance object in resource tracker
Use Migrations object in resource tracker
Use ComputeNode object in resource tracker
Some of these work items are currently ready for review: https://review.openstack.org/#/q/topic:bp/make-resource-tracker-use-objects,n,z
Dependencies¶
None
Testing¶
This does not affect existing tempest tests. Unit tests will be added for each object and existing tests will be modified to deal with the new data structure.
Documentation Impact¶
No new features or API changes so no document impact.
