Support OCI Image spec field Platform.features #38715
Description
Proposal: Support OCI Image spec platform features
Using node specific features/resources (e.g hardware) which requires to schedule a different image on each system is not easily achieved today.
Similar to platform decisions made for a CPU architecture (arm64,amd64,ppcle) a mechanism to express those features is proposed here. Extending this mechanism, the engine would not only choose an image based on Architecture, operating system and CPU variant, but also on arbitrary features, configured on an engine (node) basis.
To implement this, the platform object already provides a features field, which might be used.
- features: array of strings
This property is RESERVED for future versions of the specification.
Generic Example / How this could look like
-
Use example image manifest list on Docker Hub (qnib/plain-manifestlist)
image: qnib/plain-manifestlist manifests: - image: qnib/plain-featuretest:test1 platform: architecture: amd64 os: linux features: - test1 - image: qnib/plain-featuretest:test2 platform: architecture: amd64 os: linux features: - test2 -
Start two daemons with different platform features
Either by providing the
--platform-featureas CLI flag:hostA $ dockerd --platform-feature=test1 hostB $ dockerd --platform-feature=test2Or by setting platform features in
daemon.json:hostA $ cat /.../daemon.json { … “platform-features”: [“test1”] } hostB $ cat /.../daemon.json { … “platform-features”: [“test2”] } -
Pull the image on both daemons
hostA $ docker image pull qnib/plain-manifestlist hostA $ docker image inspect -f '{{.Id}}' qnib/plain-manifestlist sha256:ef0c26e6eccd9f20e1dde8dad63b95f5be2236cb27498895ed3888a5fee83c54 hostB $ docker image pull qnib/plain-manifestlist hostB $ docker image inspect -f '{{.Id}}' qnib/plain-manifestlist sha256:25833f2c141b60d2107d33989e847b46eaff37a17d13e1220bea8106b0137a26Note: The two resulting container images have different IDs as they are chosen according to the field
platform-features.
Checklist / Proposed next steps
- opencontainers/image-spec
- include
platform.features(example implementation)
- include
- containerd/containerd
- include new field into Matcher (example implementation)
- moby/moby
- add platform feature to daemon configuration (example implementation)
- add platform features as cli parameter (example implementation)
- change imagePuller in ImageService to recognize configured
platform.features(example implementation)
Practical application of example above
GPU case in which different CUDA drivers are installed
- HostA: Server with CUDA90 requiring CUDA driver 390-30
{.."platform-features": "nvidia-390-30",..} - HostB: Server with CUDA92 requiring CUDA driver 396-44
{.."platform-features": "nvidia-396-44",..}
$ docker run -p 8888:8888 \
--device=/dev/nvidiactl --device=/dev/nvidia-uwm \
--device=/dev/nvidia0 qnib/cv-nccl-tf-jupyter:1.12.0
Above command would result in the instantiation of two different container images being pulled on HostA and HostB with the appropriate CUDA to match the NVIDIA driver on the host.