Open Stack

Hi,

I think the concept of allowing users to request a cpu topology, but have a few questions / concerns:

> 
> The host is exposing info about vCPU count it is able to support and the
> scheduler picks on that basis. The guest image is just declaring upper limits on
> topology it can support. So If the host is able to support the guest's vCPU
> count, then the CPU topology decision should never cause any boot failure
> As such CPU topology has no bearing on scheduling, which is good because I
> think it would significantly complicate the problem.
> 

i) Is that always true ?    Some configurations (like ours) currently ignore vcpu count altogether because what we're actually creating are VMs that are "n" vcpus wide (as defined by the flavour) but each vcpu is only some subset of the processing capacity of a physical core (There was a summit session on this: http://summit.openstack.org/cfp/details/218).  So if vcpu count isn't being used for scheduling, can you still guarantee that all topology selections can always be met ?

ii) Even if you are counting vcpus and mapping them 1:1 against cores, are there not some topologies that are either more inefficient in terms of overall host usage and /or incompatible with other topologies (i.e. leave some (spare) resource un-used in way that it can't be used for a specific topology that would otherwise fit) ?     As a provider I don't want users to be able to determine how efficiently (even indirectly) the hosts are utilised.   There maybe some topologies that I'm willing to allow (because they always pack efficiently) and others I would never allow.   Putting this into the control of the users via image metadata feels wrong in that case.     Maybe flavour extra-spec (which is in the control of the cloud provider) would be a more logical fit for this kind of property ?

iii) I can see the logic of associating a topology with an image - but don't really understand how that would fit with the image being used with different flavours.  What happens if a topology in the image just can't be implemented within the constraints of a selected flavour ?    It kind of feels as if we either need a way to constrain images to specific flavours, or perhaps allow an image to express a preferred flavour / topology, but allow the user to override these as part of the create request.

Cheers,
Phil