Open Stack

----- Original Message -----
> From: "Russell Bryant" <rbryant at redhat.com>
> To: openstack-dev at lists.openstack.org
> Sent: Wednesday, August 7, 2013 10:36:04 AM
> Subject: Re: [openstack-dev] [Nova] Hypervisor Version Support
> 
> On 08/07/2013 10:14 AM, Andrew Laski wrote:
> > On 08/07/13 at 07:38am, Kaushik Chandrashekar wrote:
> >> Hi All,
> >>
> >> We are working on adding hypervisors version support for xen,
> >> https://blueprints.launchpad.net/nova/+spec/xen-support-for-hypervisor-versions
> >>
> >>
> >> The initial design is,
> >>
> >>   1. The image would have a property with hypervisor version
> >> requirements,
> >>   in this format '>=6.0,<6.2'
> >>   2. The host state manager would have the hypervisor version loaded in
> >>   (6,0,1) format.
> >>   3. If the hypervisor versions are present in both of these, the
> >>   image_props_filter would filter hypervisors based on them.
> >>  
> >> https://review.openstack.org/#/c/36073/15/nova/scheduler/filters/image_props_filter.py
> >>
> >>
> >> We want to generalise this versioning for all hypervisors. So we are
> >> thinking of having "a.b.c.d" or (a, b, c ,d) as the version type where a,
> >> b, c, d are numbers. Do you see any hypervisors that have a different
> >> versioning format?
> > 
> > Why do you want to generalize the versioning for all hypervisors?  I'm
> > not sure I see the benefit versus using the version as reported by the
> > hypervisor.  Especially since you're looking to compare against non
> > generalized versions based on your examples.
> 
> I guess to ensure you can do comparison operations (<, >, etc)?
> 

I've opened a bug that I think might be tangentially related, it has to do with version number storage:
https://bugs.launchpad.net/nova/+bug/1207058

In summary, the column hypervisor_version (on the compute_nodes table) is currently an int(11) and that means version numbers like "5.10.1" have to map to a single integer. It's a mapping that is bound to be wonky. 

But, mapping it to a vector like (5, 10, 1) is easy, so in general I like the idea. Since version "numbers" could be "5.10.1u7" or something crazy ... like "froyo" ... I was asking for the hypervisor_version (or any "version" entity really) to be stored as a string. If you have some screwy versioning scheme where you use nicknames for Jazz musicians then that's up to your hypervisor's drivers/filters to figure out how to map that into an algorithm for figuring out ordinality. The problem is that it isn't always engineers that get to decide version numbers at companies, sometimes marketing teams set them and set them in ways not conducive to numerical analysis by machines.

For all the cases I know of today, splitting into a vector of integers based on when a non-integer was encountered is the right thing to do... but you never know... some vendor might decide to start naming their versions based on desserts or jazz musicians... and that's fine as long as the maintainers can figure out some algorithm for dealing with it. IMHO.


# Shawn Hartsock