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. |
nickethier
left a comment
There was a problem hiding this comment.
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.gofile 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.