Virt Driver Objects Support (Juno Work)¶
This blueprint represents the remaining work to be done in Juno around moving the virt drivers to using objects instead of raw conductor methods. This is important because objects provide versioning of the actual data, which supports our upgrade goals.
Nova virt drivers still send and receive unversioned bundles of data using conductor methods, which is problematic during an upgrade where the format of the data has changed across releases.
Migrate uses of raw conductor methods in the virt drivers to objects. For example, consider this:
instance = conductor.instance_get_by_uuid(context, uuid) conductor.instance_update(context, instance['uuid'], host='foo')
instance = instance_obj.Instance.get_by_uuid(context, uuid) instance.host = 'foo' instance.save()
Using the objects mechanism allows older code to interact with newer code, backleveling the format of the instance object as necessary.
This is the accepted direction of the project to solve this problem. However, alternatives would be:
Don’t solve the problem and continue using unversioned data
Attempt to enforce version bumps of individual methods when any data (including nested downstream data) has changed
Data model impact¶
REST API impact¶
In general, conversion of code to use objects does not affect notifications. However, at times, emission of notifications is embedded into an object method to achieve higher consistency about when and how the notifications are sent. No such changes are antitipated in this work, but it’s always a possibility.
Other end user impact¶
Other deployer impact¶
Moving to objects enhances the ability for deployers to incrementally roll out new code. It is, however, largely transparent for them.
This is normal refactoring, so the impact is minimal. In general, objects-based code is easier to work with, so long-term it is a win for the developers.
- Primary assignee:
The following virt driver methods still need attention:
There is a cross-dependency between this blueprint and the following:
At times, a virt driver will need to be passed an object by the compute manager, and thus finishing the conversion of a virt driver method requires the calling compute manager method to be converted as well.
In general, unit tests require minimal change when this happens, depending on how the tests are structured. Ideally, they are already mocking out database calls, which means the change to objects is a transparent one. In reality, this usually means minor tweaking to the tests to return whole data models, etc.