Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

config-linux: Move 'disableOOMKiller' under 'memory'? #806

Closed
wking opened this issue May 11, 2017 · 1 comment
Closed

config-linux: Move 'disableOOMKiller' under 'memory'? #806

wking opened this issue May 11, 2017 · 1 comment

Comments

@wking
Copy link
Contributor

wking commented May 11, 2017

It's backed by memory.oom_control (see the in-flight #745), so I expect it should go with the rest of the memory-controller config. I expect consistency in these groupings will be useful as we work through #746.

Looking at the history, the initial request landing a setting for this in the Docker/OCI ecosystem seems to be docker-archive/libcontainer#417, which added Cgroup.OomKillDisable. That commit was carried from libcontainer into runC (opencontainers/runc@295c7086) where it is now Resources.OomKillDisable. From runC it was carried into this repo (with some renaming) in #51. Subsequent early doc updates landed in #137 and #199. In none of those can I find discussion about why the setting is not already under memory. I expect the reason is that the runC structures are flat, so “under memory” is not a thing there. But in this spec, resources has per-controller sub-properties. The fact that disableOOMKiller belonged to the memory controller may have been overlooked in #51 and never revisited until this issue.

I'm happy to submit a PR if the move sounds appropriate.

@wking
Copy link
Contributor Author

wking commented May 31, 2017

If we want this before 2.0, it needs to go in the 1.0.0 milestone. If we don't want this before 2.0, and are ok splitting the memory controller across multiple linux.resources entries, then maintainers should close this issue with a note to that effect.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant