Open Stack

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 <sgordon at redhat.com> wrote:

> Forwarding to openstack-operators as I think some operator feedback on
> expectations here would be useful.
>
> ----- Forwarded Message -----
> > From: "Chris Friesen" <chris.friesen at windriver.com>
> > To: openstack-dev at 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-request at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20150828/8883e8e8/attachment.html>