Open Stack

On 08/07/13 at 08:17am, Shawn Hartsock wrote:
>
>----- 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.

This makes sense to me.  If Nova virt drivers only expose ascending 
numerical versions then we can do easy version comparisons in places 
like scheduler filters.  But when the internal version isn't numerical I 
still don't think we've fully solved the issue.

What's still bugging me a bit is how we handle the comparisons to user 
input outside of the virt driver, like in the scheduler.  Does the 
scheduler need to pass versions to a compute node in order to have the 
virt driver map it properly, or do we require that versions matching the 
host_state hypervisor_version are used by users?  Or maybe we just 
accept that this case doesn't work.

>
>
># Shawn Hartsock
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev