Forwarding to openstack-operators as I think some operator feedback on expectations here would be useful.
----- Forwarded Message ----- > From: "Chris Friesen" <chris.frie...@windriver.com> > To: openstack-...@lists.openstack.org > Sent: Tuesday, August 18, 2015 7:34:11 AM > Subject: Re: [openstack-dev] [nova] should we allow overcommit for a single > VM? > > 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Steve Gordon, RHCE Sr. Technical Product Manager, Red Hat Enterprise Linux OpenStack Platform _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators