On Tue, Nov 10, 2020 at 6:35 PM Luca Boccassi wrote:
>
> On Tue, 2020-11-10 at 17:22 +, Luca Boccassi wrote:
> > On Tue, 2020-11-10 at 18:12 +0100, Francis Moreau wrote:
> > > On Tue, Nov 10, 2020 at 2:43 PM Luca Boccassi wrote:
> > > > On Tue, 2020-11-10 at 11:50 +0100, Francis Moreau wrote:
Hi All,
I've checked the history and logic of the 16M space check for /run as
presented in https://github.com/systemd/systemd/pull/5219.
But I'm wondering why choose this number (16M)? Is there some criteria
or is it based on experience?
Best Regards,
Chen Qi
_
On Mi, 18.11.20 16:26, ChenQi (qi.c...@windriver.com) wrote:
> Hi All,
>
> I've checked the history and logic of the 16M space check for /run as
> presented in https://github.com/systemd/systemd/pull/5219.
> But I'm wondering why choose this number (16M)? Is there some criteria or is
> it based on
Starting sometime on Nov 20, some of the hardware used for Ubuntu CI
tests will be down for maintenance, and it's likely some or all Ubuntu
CI test runs will fail until the hardware is back up. I don't know the
specific length of time it will take, but the maintenance window has
been scheduled from
Thanks for the details.
On Mon, Nov 16, 2020 at 09:30:20PM +0300, Andrei Enshin wrote:
> I see the kubelet crash with error: «Failed to start ContainerManager failed
> to initialize top level QOS containers: root container [kubepods] doesn't
> exist»
> details: https://github.com/kubernetes/ku
Thank you for checking!
Yes, it clearly seems that systemd and kubelet in such setup shares cgroups
which is not supposed.
We will prioritize moving our cluster to use systemd cgroup driver to avoid
such conflict.
Also I think it would be good to have extra check on kubelet side to avoid
runni
