On Tue, Dec 22, 2020, at 2:45 PM, Tom Seewald wrote: > > If your desktop doesn't segregate apps and services into cgroups, > > systemd-oomd will kill the entire desktop whenever anything uses too > > much memory, because the desktop is going to be running in the same > > cgroup as the apps that it launches. So I think desktop spins (other > > than KDE) ought to opt out of this. It should be good for all Fedora > > editions, though (including Workstation, Server, Atomic, CoreOS), and > > also for KDE spin. > > How will this work on headless systems like Fedora Server, Atomic, and > CoreOS? Will it be expected that users manually create their own > cgroups? This should really be called out in the change. There's a lot of profound things going on here. First, just speaking for Fedora CoreOS I am skeptical of us just turning this on by default. It's tricky because I can see this potentially being beneficial for "self managed containers" (i.e. a few FCOS nodes with manually set up containers) but a major use case of FCOS is Kubernetes (e.g. OKD, Typhoon, upstream kubeadm etc.) and I don't see any mention about integration with kubelet. Today requests/limits are strongly emphasized: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits Now from experience it's definitely common for people to deploy pods without any limits, and that can benefit from better low-memory/OOM handling. Kubelet already has some of that code: https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/#node-oom-behavior There's an even more obvious stumbling block that FCOS doesn't set up swap by default, and kubelet explicitly fails if it's enabled. Though it looks like there's recent movement in that area: https://github.com/kubernetes/kubernetes/issues/53533 But basically unless someone does groundwork on what swap looks like for FCOS (particularly in cloud instances) and has at least links to kubelet integration I'd expect this to be off on FCOS. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
