30d5bacb19
This review syncs the state of launchpad with the spec repo for things implemented up to liberty-3. There are no changes to the specs, just things being moved around. Change-Id: I930d33532b268b6e933c8be06a0569c20fd09586
4.1 KiB
Make Resource Tracker Use Objects
https://blueprints.launchpad.net/nova/+spec/make-resource-tracker-use-objects
This blueprint was approved for Kilo but some patches missed the feature freeze. This proposal is to complete the remaining patches in Liberty.
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
- PciDevicePool
The ComputeNode object was modified during the Kilo cycle to include required fields. A small amount of cleanup is needed around the PciDevicePool object to correct assignment of tags and the API samples and tests associated with the os-pci API. PciDevicePool is used in the ComputeNode object so this is required before finally replacing compute node data structures in the resource tracker with the ComputeNode object.
The other objects were added to the resource tracker during Kilo.
Alternatives
None.
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.
REST API impact
None. The current tests and API samples for pci stats are incorrect and will be fixed. This does not change the relvant API, so although the samples change, the API doesn't.
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 the remaining changes in this blueprint and the format of data stored in the fields of the database will not change. This means that a combination of Kilo and Liberty 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
These are the remaining work items left to complete the blueprint.
- 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
The os-pci API response samples will be correct. There will be no new feature and the APIs will not change, but API samples appear in the documentation so this will cause a minor documentation impact.