Open Stack

After reading up on the proposed design I have some concerns, primarily around the use of image properties to represent the topology.

While I see the relationship between images and CPU topology (as referenced in the wiki Windows licenses and its restrictions on sockets being a prime example) it seems very confusing to be defining information about the CPU topology in 2 places. Flavors already define a maximal number of CPUs that can be allocated and all scheduling decisions related to CPU today use the value of VCPU specified by the flavor. 

I foresee the following operational issues with having these split:
Having CPU topology restrictions in the image may lead to the inability to resize VMs to take advantage of additional compute power. Its not uncommon in enterprise deployments for VMs to be resized as the need for the services running on the VM increases. If the image is defining a portion of the topology then resizing a VM may result in an incompatible topology or a sub-optimial topology. This could lead to resizes requiring a rebuild of the VM.
A single image may have a number of  valid CPU topologies. Work would have to be done to allow the user to select which topology they wanted or images would have to be duplicated multiple times just to specify alternate, valid CPU topologies.

The flavor should specify the CPU topology as well as the maximum VCPU count. This should allow resizes to work with minimal change and it avoids the need for complex selection logic from multiple valid topologies, or duplication of images. Additionally, the path of least resistance is to simply represent this as extra_specs on the flavor. Finally extra_specs has the benefit of already being fully supported by the CLI and Horizon.

Images would still need the ability to specify restrictions on the topology. It should be fairly easy to enhance the existing core filter of the scheduler to handle the basic compatibility checks required to validate that a a given image and flavor are compatible (Note: I suspect this has to occur regardless of the implementation as having the image specify the topology could still lead to incompatible combinations). Adding restrictions 

--
Chet Burgess
Vice President, Engineering | Metacloud, Inc.
Email: cfb at metacloud.com | Tel: 855-638-2256, Ext. 2428

On Nov 19, 2013, at 4:15 , Daniel P. Berrange <berrange at redhat.com> wrote:

> For attention of maintainers of Nova virt drivers
> 
> A while back there was a bug requesting the ability to set the CPU
> topology (sockets/cores/threads) for guests explicitly
> 
>   https://bugs.launchpad.net/nova/+bug/1199019
> 
> I countered that setting explicit topology doesn't play well with
> booting images with a variety of flavours with differing vCPU counts.
> 
> This led to the following change which used an image property to
> express maximum constraints on CPU topology (max-sockets/max-cores/
> max-threads) which the libvirt driver will use to figure out the
> actual topology (sockets/cores/threads)
> 
>  https://review.openstack.org/#/c/56510/
> 
> I believe this is a prime example of something we must co-ordinate
> across virt drivers to maximise happiness of our users.
> 
> There's a blueprint but I find the description rather hard to
> follow
> 
>  https://blueprints.launchpad.net/nova/+spec/support-libvirt-vcpu-topology
> 
> So I've created a standalone wiki page which I hope describes the
> idea more clearly
> 
>  https://wiki.openstack.org/wiki/VirtDriverGuestCPUTopology
> 
> Launchpad doesn't let me link the URL to the blueprint since I'm not
> the blurprint creator :-(
> 
> Anyway this mail is to solicit input on the proposed standard way to
> express this which is hypervisor portable and the addition of some
> shared code for doing the calculations which virt driver impls can
> just all into rather than re-inventing
> 
> I'm looking for buy-in to the idea from the maintainers of each
> virt driver that this conceptual approach works for them, before
> we go merging anything with the specific impl for libvirt.
> 
> Regards,
> Daniel
> -- 
> |: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
> |: http://libvirt.org              -o-             http://virt-manager.org :|
> |: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
> |: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131221/38b9785b/attachment.html>