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
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
