Make Resource Tracker Use Objects

https://blueprints.launchpad.net/nova/+spec/make-resource-tracker-use-objects

This blueprint was approved for Icehouse 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.

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:

  • host_ip

  • 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

  • supported_instances

When complete there will be 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 the Juno-1 timeframe 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:

host_ip

Database field type: varchar(39)

Object field type: fields.IPAddressField()

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 Icehouse. 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 Icehouse and Juno 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

Other contributors:

alexisl

Work Items

  • Use flavor object in resource tracker - (merged in Icehouse)

  • Use Service object in resource tracker

  • Use Instance object in resource tracker

  • Use Migrations object in resource tracker

  • Use ComputeNode object in resource tracker

Several 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.