As an operator, I would have no problem with changing the behavior to match the NUMA case, no single VM should overcommit. I also agree that this type of scenario is unlikely to hit production installs, instead it could potentially hit a lot of CI / staging installs.
- jlk On Tue, Aug 18, 2015 at 10:22 AM, Steve Gordon <[email protected]> wrote: > Forwarding to openstack-operators as I think some operator feedback on > expectations here would be useful. > > ----- Forwarded Message ----- > > From: "Chris Friesen" <[email protected]> > > To: [email protected] > > 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: > [email protected]?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 > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
