Open Stack

On 08/18/2015 06:56 AM, Nikola Đipanov wrote:
> On 08/17/2015 08:22 PM, Chris Friesen wrote:

>> The basic question is, if a host has X CPUs in total for VMs, and a
>> single instance wants X+1 vCPUs, should we allow it?  (Regardless of
>> overcommit ratio.)  There is also an equivalent question for RAM.
>>
>> Currently we have two different answers depending on whether numa
>> topology is involved or not.  Should we change one of them to make it
>> consistent with the other?  If so, a) which one should we change, and b)
>> how would we do that given that it results in a user-visible behaviour
>> change?  (Maybe a microversion, even though the actual API doesn't
>> change, just whether the request passes the scheduler filter or not?)
>>
>
> I would say that the "correct" behavior is what NUMA fitting logic does,
> and that is to not allow instance to over-commit against itself, and we
> should fix "normal" (non-NUMA) over-commit. Allowing the instance to
> over-commit against itself does not make a lot of sense, however it is
> not something that is likely to happen that often in real world usage -
> I would imagine operators are unlikely to create flavors larger than
> compute hosts.

This is a good point, in any "real" deployment it likely won't be an issue.  We 
only ran into it because we were testing on a minimal-sized compute node running 
in a VM on a designer box.

> I am not sure that this has anything to do with the API thought. This is
> mostly a Nova internal implementation detail. Any nova deployment can
> fail to boot an instance for any number of reasons, and this does not
> affect the API response of the actual boot request.

Arguably it would be changing the behaviour of a boot request.  Currently it 
would pass the scheduler and boot up, and we're talking about making it fail the 
scheduler filter.  That's an externally-visible change in behaviour.  (But as 
you say it's unlikely that it will be hit in the real world.)

Chris