On 08/10/2015 10:11 AM, Dugger, Donald D wrote:
In re: Different architectures.

I'm not saying we should create architecture specific definitions in our
APIs.  I like the idea of capabilities being exposed as arbitrary strings
like "AES" or "AltiVec".  An Intel user would be providing an IA architecture
image and should know that it makes no sense to request "AltiVec"
capabilities (and that request would correctly fail as either the image
wouldn't run on the selected host or no host would be selected).

I'm looking for Nova to provide a common way of exposing and requesting host
capabilities and you just use appropriate architecture specific strings when
using these common interfaces.

There are some complications.

For non-x86 architectures they don't have the equivalent of "CPU features" exposed. It's basically all encoded in the CPU model.

For x86, you can't just pick features, you actually need to specify the guest CPU model in order to ensure that live-migration is possible between hosts with potentially different host CPU models. Also, the guest CPU model is not sufficient by itself, because different cloud vendors mask out different CPU features from the guest. (Still not totally sure why, but apparently they do.)

So specifically for CPU model/features I think we'd want to allow the specification of a "CPU flavor", which would expose a vCPU model and (if appropriate) a set of features that could be queried. These would be created by the admin, likely to match the underlying hardware available in the cloud. (Since it doesn't buy you anything to expose CPU models that don't match up with a host CPU model.)

I'm not quite sure how to deal with clouds that have multiple hypervisors, since the different hypervisors have subtly different virtual CPU models/features.

Chris

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to