Blocker Description
Currently when user launches a container from a Docker image via universal containerizer, we always handle the whiteout files in ProvisionerProcess::__provision() regardless of which backend is used.
However this is actually not correct, because the way to handle whiteout files is backend dependent, that means for different backends, we need to handle whiteout files in different ways, e.g.:
- AUFS backend: It seems the AUFS whiteout (.wh.<filename/dirname> and .wh..wh..opq) is the whiteout standard in Docker (see this comment for details), so that means after the Docker image is pulled, its whiteout files in the store are already in aufs format, then we do not need to do anything about whiteout file handling because the aufs mount done in AufsBackendProcess::provision() will handle it automatically.
- Overlay backend: Overlayfs has its own whiteout files (see this doc for details), so we need to convert the aufs whiteout files to overlayfs whiteout files before we do the overlay mount in OverlayBackendProcess::provision which will automatically handle the overlayfs whiteout files.
- Copy backend: We need to manually handle the aufs whiteout files when we copy each layer in CopyBackendProcess::_provision().
Attachments
Issue Links
- is duplicated by
-
MESOS-6404 My program cannot access a .so file while being run with mesos containerization on a docker image.
-
- Resolved
-
- supercedes
-
-
- Resolved
-