<div dir="ltr">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.</div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br></div><div dir="ltr">- jlk</div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Aug 18, 2015 at 10:22 AM, Steve Gordon <span dir="ltr"><<a href="mailto:sgordon@redhat.com" target="_blank">sgordon@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Forwarding to openstack-operators as I think some operator feedback on expectations here would be useful.<br>
<br>
----- Forwarded Message -----<br>
> From: "Chris Friesen" <<a href="mailto:chris.friesen@windriver.com">chris.friesen@windriver.com</a>><br>
> To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
> Sent: Tuesday, August 18, 2015 7:34:11 AM<br>
> Subject: Re: [openstack-dev] [nova] should we allow overcommit for a single VM?<br>
><br>
> On 08/18/2015 06:56 AM, Nikola Đipanov wrote:<br>
> > On 08/17/2015 08:22 PM, Chris Friesen wrote:<br>
><br>
> >> The basic question is, if a host has X CPUs in total for VMs, and a<br>
> >> single instance wants X+1 vCPUs, should we allow it? (Regardless of<br>
> >> overcommit ratio.) There is also an equivalent question for RAM.<br>
> >><br>
> >> Currently we have two different answers depending on whether numa<br>
> >> topology is involved or not. Should we change one of them to make it<br>
> >> consistent with the other? If so, a) which one should we change, and b)<br>
> >> how would we do that given that it results in a user-visible behaviour<br>
> >> change? (Maybe a microversion, even though the actual API doesn't<br>
> >> change, just whether the request passes the scheduler filter or not?)<br>
> >><br>
> ><br>
> > I would say that the "correct" behavior is what NUMA fitting logic does,<br>
> > and that is to not allow instance to over-commit against itself, and we<br>
> > should fix "normal" (non-NUMA) over-commit. Allowing the instance to<br>
> > over-commit against itself does not make a lot of sense, however it is<br>
> > not something that is likely to happen that often in real world usage -<br>
> > I would imagine operators are unlikely to create flavors larger than<br>
> > compute hosts.<br>
><br>
> This is a good point, in any "real" deployment it likely won't be an issue.<br>
> We<br>
> only ran into it because we were testing on a minimal-sized compute node<br>
> running<br>
> in a VM on a designer box.<br>
><br>
> > I am not sure that this has anything to do with the API thought. This is<br>
> > mostly a Nova internal implementation detail. Any nova deployment can<br>
> > fail to boot an instance for any number of reasons, and this does not<br>
> > affect the API response of the actual boot request.<br>
><br>
> Arguably it would be changing the behaviour of a boot request. Currently it<br>
> would pass the scheduler and boot up, and we're talking about making it fail<br>
> the<br>
> scheduler filter. That's an externally-visible change in behaviour. (But as<br>
> you say it's unlikely that it will be hit in the real world.)<br>
><br>
> Chris<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Steve Gordon, RHCE<br>
Sr. Technical Product Manager,<br>
Red Hat Enterprise Linux OpenStack Platform<br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</font></span></blockquote></div><br></div>