OCI Runtime Spec v1.3
We are delighted to announce the release of the OCI Runtime Spec v1.3.0. This release contains 24 pull requests that were merged since the 1.2.1 release. We appreciate everybody who contributed to this release.
What is the OCI Runtime Spec?
The OCI Runtime Spec defines the behavior and the configuration interface of low-level container runtimes such as runc. The spec is also implemented by crun, youki, gVisor, Kata Containers, and others. These low-level container runtimes are usually called from high-level container runtimes such as containerd and CRI-O.
Additions
config-vm: add hwConfig object (#1209)
The vm.hwConfig object is added to describe hardware configuration that should be passed to a VM-based container runtime.
e.g., number of vCPUs, amount of memory, and the device tree.
config-linux: add intelRdt.schemata field (#1230)
The linux.intelRdt.schemata field is added to address the complexity of separate schema fields and to resolve the issue of supporting currently uncovered
Intel Resource Director Technology (RDT) features, such as
- L2 cache allocation
- Code and Data Prioritization (CDP).
config-linux: add netDevices object (#1271)
The linux.netDevices field is added to provide a declarative way to specify which host network devices should be moved into a container’s network namespace.
config-linux: add memoryPolicy object (#1282)
The linux.memoryPolicy object is added to specify NUMA policies.
config-freebsd: add the spec for FreeBSD (#1286)
The freebsd object is added to implement containers using FreeBSD jails.
The following implementations are known:
config-linux: add intelRdt.enableMonitoring field (#1287)
The linux.intelRdt.enableMonitoring field is added to enable resctrl monitoring features.
This fields replaces the enableCMT and enableMBM fields, available in the spec versions v1.1.0 through v1.2.1.
Their semantics were loosely defined and there were no known implementations, so this change should not affect any existing implementations.
Other changes
See here for the list of the full changes.
What’s next?
See the GitHub issues and the pull requests for the proposals toward the future releases. e.g.,
You are always welcome to submit your own proposals too.