Open Stack

On the Hyper-V side we are also interested in this feature as for example VHDX images are supported starting with Hyper-V Server 2012.

On the versioning convention, I don't see particular issues as long as the version ordering arithmetic works. Said that, I'd vote for a consistent numeric only a.b.c.d format across all drivers (e.g. major.minor.build.revision) as already suggested by John.


On 07.08.2013, at 16:57, "John Garbutt" <john at johngarbutt.com> wrote:

> I guess this is the same issue we faced with the capabilities filters
> and things, when drivers don't report stats in a consistent format.
> 
> If we dictate the driver reports things in a standard format, it will
> make our lives much easier, I think.
> 
> Currently, some report their own format, and a few (not just libvirt)
> use the libvirt format. It would seem better to report something more
> standard like "a.b.c.d". But to be honest, I think consistency is the
> key here.
> 
> John
> 
> On 7 August 2013 15:36, Russell Bryant <rbryant at redhat.com> wrote:
>> 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)?
>> 
>> --
>> Russell Bryant
>> 
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev