Add containerd-shim plumbing for job containers #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* Add the necessary plumbing in containerd shim to be able to create a job container if asked for via the annotation. Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Jun 25, 2021
Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Jun 25, 2021
Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Jul 1, 2021
This adds basic directory mount support for job containers. As any path on the host is already accessible from the container, the concept of volume mounts is a bit funny for job containers. However, it still makes sense to treat the volume mount point where the container image is mounted as where most things should be found regarding the container. The manner in which this is done is by appending the container mount path for the volume to where the rootfs volume is mounted on the host and then symlinking it. So: Container rootfs volume path = "C:\C\123456789abcdefgh\" Example #1 -------------- { "host_path": "C:\mydir" "container_path": "\dir\in\container" } "C:\mydir" would be symlinked to "C:\C\123456789abcdefgh\dir\in\container" Example #2 --------------- Drive letters will be stripped { "host_path": "C:\mydir" "container_path": "C:\dir\in\container" } "C:\mydir" would be symlinked to "C:\C\123456789abcdefgh\dir\in\container" Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Jul 1, 2021
This adds basic directory mount support for job containers. As any path on the host is already accessible from the container, the concept of volume mounts is a bit funny for job containers. However, it still makes sense to treat the volume mount point where the container image is mounted as where most things should be found regarding the container. The manner in which this is done is by appending the container mount path for the volume to where the rootfs volume is mounted on the host and then symlinking it. So: Container rootfs volume path = "C:\C\123456789abcdefgh\" Example #1 -------------- { "host_path": "C:\mydir" "container_path": "\dir\in\container" } "C:\mydir" would be symlinked to "C:\C\123456789abcdefgh\dir\in\container" Example #2 --------------- Drive letters will be stripped { "host_path": "C:\mydir" "container_path": "C:\dir\in\container" } "C:\mydir" would be symlinked to "C:\C\123456789abcdefgh\dir\in\container" Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Jul 1, 2021
This adds basic directory mount support for job containers. As any path on the host is already accessible from the container, the concept of volume mounts is a bit funny for job containers. However, it still makes sense to treat the volume mount point where the container image is mounted as where most things should be found regarding the container. The manner in which this is done is by appending the container mount path for the volume to where the rootfs volume is mounted on the host and then symlinking it. So: Container rootfs volume path = "C:\C\123456789abcdefgh\" Example #1 -------------- { "host_path": "C:\mydir" "container_path": "\dir\in\container" } "C:\mydir" would be symlinked to "C:\C\123456789abcdefgh\dir\in\container" Example #2 --------------- Drive letters will be stripped { "host_path": "C:\mydir" "container_path": "C:\dir\in\container" } "C:\mydir" would be symlinked to "C:\C\123456789abcdefgh\dir\in\container" Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Jul 6, 2021
This adds basic directory mount support for job containers. As any path on the host is already accessible from the container, the concept of volume mounts is a bit funny for job containers. However, it still makes sense to treat the volume mount point where the container image is mounted as where most things should be found regarding the container. The manner in which this is done is by appending the container mount path for the volume to where the rootfs volume is mounted on the host and then symlinking it. So: Container rootfs volume path = "C:\C\123456789abcdefgh\" Example #1 -------------- { "host_path": "C:\mydir" "container_path": "\dir\in\container" } "C:\mydir" would be symlinked to "C:\C\123456789abcdefgh\dir\in\container" Example #2 --------------- Drive letters will be stripped { "host_path": "C:\mydir" "container_path": "C:\dir\in\container" } "C:\mydir" would be symlinked to "C:\C\123456789abcdefgh\dir\in\container" Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Jul 6, 2021
This adds basic directory mount support for job containers. As any path on the host is already accessible from the container, the concept of volume mounts is a bit funny for job containers. However, it still makes sense to treat the volume mount point where the container image is mounted as where most things should be found regarding the container. The manner in which this is done is by appending the container mount path for the volume to where the rootfs volume is mounted on the host and then symlinking it. So: Container rootfs volume path = "C:\C\123456789abcdefgh\" Example #1 -------------- { "host_path": "C:\mydir" "container_path": "\dir\in\container" } "C:\mydir" would be symlinked to "C:\C\123456789abcdefgh\dir\in\container" Example #2 --------------- Drive letters will be stripped { "host_path": "C:\mydir" "container_path": "C:\dir\in\container" } "C:\mydir" would be symlinked to "C:\C\123456789abcdefgh\dir\in\container" Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Jul 9, 2021
This adds basic directory mount support for job containers. As any path on the host is already accessible from the container, the concept of volume mounts is a bit funny for job containers. However, it still makes sense to treat the volume mount point where the container image is mounted as where most things should be found regarding the container. The manner in which this is done is by appending the container mount path for the volume to where the rootfs volume is mounted on the host and then symlinking it. So: Container rootfs volume path = "C:\C\123456789abcdefgh\" Example #1 -------------- { "host_path": "C:\mydir" "container_path": "\dir\in\container" } "C:\mydir" would be symlinked to "C:\C\123456789abcdefgh\dir\in\container" Example #2 --------------- Drive letters will be stripped { "host_path": "C:\mydir" "container_path": "C:\dir\in\container" } "C:\mydir" would be symlinked to "C:\C\123456789abcdefgh\dir\in\container" Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Jul 9, 2021
This adds basic directory mount support for job containers. As any path on the host is already accessible from the container, the concept of volume mounts is a bit funny for job containers. However, it still makes sense to treat the volume mount point where the container image is mounted as where most things should be found regarding the container. The manner in which this is done is by appending the container mount path for the volume to where the rootfs volume is mounted on the host and then symlinking it. So: Container rootfs volume path = "C:\C\123456789abcdefgh\" Example #1 -------------- { "host_path": "C:\mydir" "container_path": "\dir\in\container" } "C:\mydir" would be symlinked to "C:\C\123456789abcdefgh\dir\in\container" Example #2 --------------- Drive letters will be stripped { "host_path": "C:\mydir" "container_path": "C:\dir\in\container" } "C:\mydir" would be symlinked to "C:\C\123456789abcdefgh\dir\in\container" Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Jul 20, 2021
This change brings in the bindfltapi.dll bindings for setting up directory binds. This is intended to be used for job container volume mounts. This change also brings in a small constant that allows promoting a job object to a silo (not a server silo, aka windows server containers). This is because bindflt has the ability to create per silo bindings which is very useful. E.g. Map D:\my\dir to C:\test for silo #1 Map D:\my\other\dir to C:\test for silo #2 Processes in silo #1 and #2 will both see different directories, as well as processes on the host. If C:\test doesn't exist on the host, host processes simply won't see anything, and if it does exist they will continue to see whatever was always there. Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Aug 7, 2021
This change brings in the bindfltapi.dll bindings for setting up directory binds. This is intended to be used for job container volume mounts. This change also brings in a small constant that allows promoting a job object to a silo (not a server silo, aka windows server containers). This is because bindflt has the ability to create per silo bindings which is very useful. E.g. Map D:\my\dir to C:\test for silo #1 Map D:\my\other\dir to C:\test for silo #2 Processes in silo #1 and #2 will both see different directories, as well as processes on the host. If C:\test doesn't exist on the host, host processes simply won't see anything, and if it does exist they will continue to see whatever was always there. Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Sep 7, 2021
1. Rename to AnnotationContainerProcessDumpLocation = "io.microsoft.container.processdumplocation" from AnnotationProcessDumpLocation = "io.microsoft.processdumplocation". It really is the container that we're applying the process dump location to and the ones that will ultimately use it so this makes more sense. 2. Add a small comment on the Test_RunPodSandbox_CoreDump_LCOW test to mention that the /coredumps/core location set is actually the filename and not just a directory where the dumps will get placed. 3. Run go mod vendor in /test Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Sep 14, 2021
Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Oct 19, 2021
Remove units (InSec suffix) for any time.Duration uses for the io reconnect timeouts. Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Oct 19, 2021
Remove units (InSec suffix) for any time.Duration uses for the io reconnect timeouts. Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Oct 19, 2021
Remove units (InSec suffix) for any time.Duration uses for the io reconnect timeouts. Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Oct 19, 2021
Remove units (InSec suffix) for any time.Duration uses for the io reconnect timeouts. Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Oct 20, 2021
- Get rid of annotation to configure per container. - Swap to context.Background() instead of TODO() - Add back in return after comment that was an accident. Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Oct 21, 2021
- Get rid of annotation to configure per container. - Swap to context.Background() instead of TODO() - Add back in return after comment that was an accident. Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Oct 21, 2021
Fix DetachVHD error check and assignment. Signed-off-by: Daniel Canter <[email protected]>
dcantah
added a commit
that referenced
this pull request
Oct 21, 2021
Fix DetachVHD error check and assignment. Signed-off-by: Daniel Canter <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
if asked for via the annotation.
Signed-off-by: Daniel Canter [email protected]