Add volume mount support for job containers #1057
Conversation
|
Need to add a test here, will do shortly |
|
@jsturtevant fyi |
dcantah
force-pushed
the
jobcontainer-volume
branch
2 times, most recently
from
682dc30 to
d396770
Compare
|
I have added the necessary PR in k/k to allow this code to work @jsturtevant @dcantah PTAL kubernetes/kubernetes#103434 |
dcantah
force-pushed
the
jobcontainer-volume
branch
2 times, most recently
from
35c9d7c to
260ea4f
Compare
dcantah
force-pushed
the
jobcontainer-volume
branch
from
260ea4f to
56e057f
Compare
|
@anmaxvl Removed the k8s workaround mentioned in the last round as it's no longer needed |
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 <dcanter@microsoft.com>
dcantah
force-pushed
the
jobcontainer-volume
branch
from
56e057f to
90a193c
Compare
|
@katiewasnothere updated, ptal |
| return errors.Wrap(err, "failed to make directory for job container mount") | ||
| } | ||
|
|
||
| if err := os.Symlink(mount.Source, fullCtrPath); err != nil { |
There was a problem hiding this comment.
Is there an expectation based on standard container mount behavior that a mount over an existing path will mask the existing path? os.Symlink will fail if the target exists.
There was a problem hiding this comment.
Correct yea. At the bindflt level I'd assume there's nothing stopping a shadowing of whatever was there, but I'm not sure if hcs has any logic to disallow this. Let me give it a whirl, that's a good point.
There was a problem hiding this comment.
@msscotb Yea the behavior on Windows (and Linux but I knew this part) is to mask whatever is there. I don't know how we could mimic this without bindflt :/
There was a problem hiding this comment.
@msscotb Was this a blocking comment or just a "curious what happens in a normal container scenario"?
There was a problem hiding this comment.
@msscotb ping on this
There was a problem hiding this comment.
I don't see a better option since binding as we do for standard containers is not possible with the process isolated design current.
Related work items: microsoft#930, microsoft#962, microsoft#1004, microsoft#1008, microsoft#1039, microsoft#1045, microsoft#1046, microsoft#1047, microsoft#1052, microsoft#1053, microsoft#1054, microsoft#1057, microsoft#1058, microsoft#1060, microsoft#1061, microsoft#1063, microsoft#1064, microsoft#1068, microsoft#1069, microsoft#1070, microsoft#1071, microsoft#1074, microsoft#1078, microsoft#1079, microsoft#1081, microsoft#1082, microsoft#1083, microsoft#1084, microsoft#1088, microsoft#1090, microsoft#1091, microsoft#1093, microsoft#1094, microsoft#1096, microsoft#1098, microsoft#1099, microsoft#1102, microsoft#1103, microsoft#1105, microsoft#1106, microsoft#1108, microsoft#1109, microsoft#1115, microsoft#1116, microsoft#1122, microsoft#1123, microsoft#1126
Add volume mount support for job containers
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 dcanter@microsoft.com