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



_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to