Save hypervisor version as string rather than an integer

Registered by Aditi Raveesh on 2013-08-21

The hypervisor_version reported by vmwareapi, powervm, hyperv and the fake driver all use strings as their version number. Currently, the hypervisor_version is being saved as an integer in the compute_nodes table. It would be consistent and more convenient to store it as a string, which would avoid the need to convert it to int.

Related discussion can be found on:
https://bugs.launchpad.net/nova/+bug/1207058

Related mailing list discussion:
http://lists.openstack.org/pipermail/openstack-dev/2013-August/013197.html

Blueprint information

Status:
Not started
Approver:
Russell Bryant
Priority:
Undefined
Drafter:
Aditi Raveesh
Direction:
Needs approval
Assignee:
Aditi Raveesh
Definition:
Review
Series goal:
None
Implementation:
Not started
Milestone target:
None

Related branches

Sprints

Whiteboard

The big concern with this is how comparisons(ordering) will be handled with strings. So this blueprint needs to address how that will be handled. It could be left up to individual drivers to handle it as long as the scheduler or any filters aren't reliant on hypervisor_version. Otherwise, as was mentioned in the email thread linked above there needs to be an assurance that the string can be mapped to ordinal numbers. --alaski

Currently, in case of xen hypervisor, the hypervisor version is used as an int while doing a version comparison. In other places, the version is converted from a string to an int, and then compared. An easier approach would be to keep this consistent: save the version as a string in the db (rather than as an int), and use string comparison, such as the method is_compatible from versionutils module to make any kind of version comparisons. This would eliminate the need of multiple conversion util methods such as convert_version_to_int, and would also help maintain consistent code.
Suggestions? --aditirav

deferred from icehouse-3 to "next": http://lists.openstack.org/pipermail/openstack-dev/2014-February/026335.html

Removed from next, as next is now reserved for near misses from the last milestone --johnthetubaguy

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.