-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Use upstream libcontainer package #5437
Conversation
I made this approach as well as #5438. I prefer this one more, considering that it's more consistent with libcontainer documented use case and doesn't require maintaining any additional code beyond needed to set up container. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the only downside to this is that if a third party driver wants to use the executor they end up duplicating alot having to package their own executor, though that may actually be preferred rather than having Nomad's executor version changed out underneath you.
I agree I think this is the better way forward. Great work!
5b6404f
to
6747195
Compare
FWIW, this picked up a fix to reduce memory usage required by libcontainer in opencontainers/runc#1984 - so driver/exec no longer need large memory requirement (~70-100MB) for small processes. |
I'm going to lock this pull request because it has been closed for 120 days ⏳. This helps our maintainers find and focus on the active contributions. |
Use the upstream libcontainer package, by ensuring that executor pkg binary always has the nsenter code.
By having
libcontainer_nsenter_linux.go
file be part of the package, any binary containing the package (including tests) would be configured to run libcontainer packages properly.This doesn't change the behavior of external drivers, as they would still launch executors through plugins that invoke nomad binary to spin up the executor plugin.