Peter Hunt

I'm wondering if we should just add an exponential backoff and call it a day. We can't easily communicate to the kubelet the process is in "D" state without exiting...

> The question here would be: is this safe to run for a process (container) that might still be running for a while? hard to tell without knowing exactly the...

I think printing the internal representation of the config is a good idea. a user can piece it together but they have to take into account env vars, cli flags...

I personally don't agree with the need to store the current configuration anywhere. I think printing it is fine. the config is reconstructable from the sources cri-o is being configured...

I seem to remember this has something to do with cgroupv2. I also wonder if it's an error coming from libcontainer. @kolyshkin does anything come to mind immediately?

it does but it wasn't merged because I don't think we should delegate : https://github.com/openshift/machine-config-operator/pull/4217#issuecomment-1966909788 Basically: the problem is when kubelet creates the kubepods slice, it doesn't specify AllowedCPUs (which...

> Looks like default behavior was changed from crio-o 1.28.2 at least. This is also better to note. this is unexpected. we should have been dropping CAP_NET_RAW for a while....

interesting, I find myself wondering if containerd behaves the same or if we differ from it as well?

assigned! thanks for your interest :)

hey @plevart we are actually discussing doing just that with Brad Smith from the fedora community. We're working on propopsals for F40 to provide a package for kube, crictl and...