Add WCOW sandbox mount support #1087
Conversation
|
Should we set a certain mount type for wcow? We set the type to "bind" for Linux, but not sure if we want to use that for wcow. Right now I'm just checking the prefix instead. |
You don't need this |
I know I don't need it, seeming as how what I'm doing here works :P I was asking as for the other mount types we check against whether the type is x, y, or z but for these I'm checking whether the source has a prefix instead. Mainly wanted to know if anyone thought we might want to set a type like we do for physical-disk, virtual-disk etc. to keep it more in line. Sounds like no though |
dcantah
force-pushed
the
sandboxmount-wcow
branch
from
8f03188 to
7bf7421
Compare
dcantah
force-pushed
the
sandboxmount-wcow
branch
from
7bf7421 to
91ea115
Compare
|
@katiewasnothere Added the test you recommended, but going to wait for an answer on this #1087 (comment) before addressing that. PTAL again when you get a chance |
dcantah
force-pushed
the
sandboxmount-wcow
branch
from
22e8570 to
ecc58f7
Compare
|
@katiewasnothere @ambarve Here's the CRI pr kevpar/cri#1 to add a condition to check for these. Does this look alright to check in if anyone can give another look real quick? |
|
@katiewasnothere Updated the cri PR also kevpar/cri#1, ptal. |
dcantah
force-pushed
the
sandboxmount-wcow
branch
from
ee76c64 to
3f0695e
Compare
dcantah
force-pushed
the
sandboxmount-wcow
branch
from
3f0695e to
56651fb
Compare
This change adds sandbox mount like support for WCOW. Sandboxmounts are our LCOW
solution similar to a k8s empty dir mount. We create a directory that will house
various other subdirectories that a user can specify by supplying a sandbox:// prefix
for the host path of a mount. In the usual case the hostpath of a mount is in the context of the
physical host (e.g. I want C:\path on my machine mapped to C:\containerpath in my container),
however for sandbox mounts the host path is treated as relative to this directory we have
made in the VM. The root directory for these sandbox mounts I defined as C:\SandboxMounts
Example:
"mounts": [
{
"container_path": "C:\\test",
"host_path": "sandbox:///test"
}
]
The above will make a directory at C:\SandboxMounts\test in the Utility VM that will be mapped to
C:\\test in the container. If another container in the same pod supplied the same mount then
you would end up "sharing" this directory with the other container, meaning you would
both see anything placed/modified in this directory.
The backing storage for these mounts will be the UVMs scratch disk, which currently is always 10GB
(8.5 actually usable) as that's whats hardcoded in HCS for the call we use that generates the vhd.
For some reason the expand vhd function from HCS doesn't function for the VM scratch disk which needs
some investigation :(
Signed-off-by: Daniel Canter <dcanter@microsoft.com>
This change adds two cri-containerd tests to test WCOW sandbox mounts. One test verifies the general functionality by having two containers supply the same sandbox://<path> mount and validating that each container can see whats in the mount. Another tests verifies that if we don't supply the sandbox:/// mount for another container in the pod, it doesn't have access to the mount. Signed-off-by: Daniel Canter <dcanter@microsoft.com>
dcantah
force-pushed
the
sandboxmount-wcow
branch
from
56651fb to
92004da
Compare
|
Squashed and rebased, thanks for review! |
Related work items: microsoft#1062, microsoft#1087, microsoft#1089, microsoft#1095, microsoft#1104, microsoft#1112, microsoft#1117, microsoft#1118, microsoft#1125, microsoft#1137, microsoft#1139, microsoft#1140, microsoft#1141, microsoft#1142, microsoft#1143, microsoft#1145, microsoft#1146, microsoft#1150, microsoft#1151, microsoft#1153, microsoft#1154, microsoft#1155, microsoft#1156, microsoft#1157, microsoft#1158, microsoft#1159, microsoft#1161, microsoft#1162, microsoft#1163, microsoft#1164, microsoft#1165, microsoft#1166, microsoft#1167, microsoft#1168, microsoft#1169, microsoft#1171, microsoft#1172, microsoft#1173, microsoft#1174, microsoft#1178
This change adds sandbox mount like support for WCOW. Sandboxmounts were our LCOW
solution similar to a k8s empty dir mount. We create a directory that will house
various other subdirectories that a user can specify by supplying a sandbox:// prefix
for the host path of a mount. In the usual case the hostpath of a mount is in the context of the
physical host (e.g. I want C:\path on my machine mapped to C:\containerpath in my container),
however for sandbox mounts the host path is treated as relative to this directory we have
made in the VM. The root directory for these sandbox mounts I defined as C:\SandboxMounts
Example:
The above will make a directory at C:\SandboxMounts\test in the Utility VM that will be mapped to
C:\test in the container. If another container in the same pod supplied the same mount then
you would end up "sharing" this directory with the other container, meaning you would
both see anything placed/modified in this directory.
The backing storage for these mounts will be the UVMs scratch disk, which currently is always 10GB
(8.5 actually usable) as that's what's hardcoded in HCS for the call we use that generates the vhd.
For some reason the expand vhd function from HCS doesn't function for the VM scratch disk which needs
some investigation :(
Signed-off-by: Daniel Canter dcanter@microsoft.com