Open Stack

On 08/17/2015 08:22 PM, Chris Friesen wrote:
> 
> I tried bringing this up on the irc channel, but nobody took the bait.
> Hopefully this will generate some discussion.
> 
> I just filed bug 1485631.  Nikola suggested one way of handling it, but
> there are some complications that I thought I should highlight so we're
> all on the same page.
> 
> 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.

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.

Hope it helps,
N.