[openstack-dev] [infra] [gate] [all] openstack services footprint lead to oom-kill in the gate

Miguel Angel Ajo Pelayo majopela at redhat.com
Mon Feb 6 10:09:49 UTC 2017

Jeremy Stanley wrote:

> It's an option of last resort, I think. The next consistent flavor
> up in most of the providers donating resources is double the one
> we're using (which is a fairly typical pattern in public clouds). As
> aggregate memory constraints are our primary quota limit, this would
> effectively halve our current job capacity.

Properly coordinated with all the cloud the providers, they could create
flavours which are private but available to our tenants, where a 25-50%
more RAM would be just enough.

I agree that should probably be a last resort tool, and we should keep
looking for proper ways to find where we consume unnecessary RAM and make
sure that's properly freed up.

It could be interesting to coordinate such flavour creation in the mean
time, even if we don't use it now, we could eventually test it or put it to
work if we find trapped anytime later.

On Sun, Feb 5, 2017 at 8:37 PM, Matt Riedemann <mriedemos at gmail.com> wrote:

> On 2/5/2017 1:19 PM, Clint Byrum wrote:
>> Also I wonder if there's ever been any serious consideration given to
>> switching to protobuf? Feels like one could make oslo.versionedobjects
>> a wrapper around protobuf relatively easily, but perhaps that's already
>> been explored in a forum that I wasn't paying attention to.
> I've never heard of anyone attempting that.
> --
> Thanks,
> Matt Riedemann
> __________________________________________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170206/cdc54206/attachment.html>

More information about the OpenStack-dev mailing list