Re: [openstack-dev] [Nova] Hypervisor Version Support
On 08/06/2013 10:08 PM, 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? That seems sane to me. If anything uses a version that isn't already numeric, surely it could be mapped into a numeric scheme. If it can't, then their versioning scheme is bonkers, IMO. :-) -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Hypervisor Version Support
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. -- Thanks, Kaushik ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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)? -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Hypervisor Version Support
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 rbry...@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova] Hypervisor Version Support
On 08/07/13 at 08:17am, Shawn Hartsock wrote: - Original Message - From: Russell Bryant rbry...@redhat.com To: openstack-dev@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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
