[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: OS 1.0.7 eating memory like candies after halloween



You can recursively delete the entire events structure safely - it
*should* be /kubernetes.io/events - if that's where the events are,
then do a recursive delete of /kubernetes.io/events (be very careful,
this is rm -rf).

Derek is working an issue right now that would prevent these from
overwhelming the server.  I *think* the deployment config problem is
covered by an issue about not changing the status if there is nothing
to write.  Dan, can you verify that your change would potentially
prevent deployments from hot looping like this (do we have a rate
limiter on the image change trigger retry queue)?

On Tue, Nov 3, 2015 at 9:11 PM, Philippe Lafoucrière
<philippe lafoucriere tech-angels com> wrote:
> Ok, the issue in indeed in our etcd.
> I managed to list the keys, and I can see a LOT of "Deployment config
> \\\"gemnasium-nginx-rails\\\" blocked by multiple errors:\\n\\n\\t* \\n\\t*
> \\n\\t*"
> The Glusterfs issue we had in the other thread has generated a lot of
> failure events, and apparently openshift can't handle them. Is there a way
> to clean these events for testing?
>
> Thanks


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]