From fd698a81c7b9779fd5c60ad94deb97ed363b1468 Mon Sep 17 00:00:00 2001 From: Tariq Ibrahim Date: Fri, 7 Jul 2023 00:52:25 -0700 Subject: [PATCH] minor documentation improvements --- CONTRIBUTING.md | 2 +- README.md | 13 ++++++------- SPEC.md | 16 ++++++++-------- 3 files changed, 15 insertions(+), 16 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 4438198..8a47c11 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -5,7 +5,7 @@ We welcome contributions. In addition to signing your work as described in the section below we ask that the following guidelines be considered when opening, reviewing, and merging pull requests. -* No one should merge their own code or code from their own organzation +* No one should merge their own code or code from their own organization * Reviewers should included people from an organization that is not your own * If no changes have been requested by other reviewers the (last) reviewer merges the pull request on approval diff --git a/README.md b/README.md index c17b35b..725eb2a 100644 --- a/README.md +++ b/README.md @@ -4,8 +4,7 @@ ## What is CDI? -CDI (Container Device Interface), is a [specification](SPEC.md), for container- -runtimes, to support third-party devices. +CDI (Container Device Interface), is a [specification](SPEC.md), for container-runtimes, to support third-party devices. It introduces an abstract notion of a device as a resource. Such devices are uniquely specified by a fully-qualified name that is constructed from a vendor @@ -24,7 +23,7 @@ handled by the orchestrator). Because of this focus, the CDI specification is simple to implement and allows great flexibility for runtimes and orchestrators. Note: The CDI model is based on the Container Networking Interface (CNI) model -and specification. +and [specification](https://github.com/containernetworking/cni/blob/main/SPEC.md). ## Why is CDI needed? @@ -35,8 +34,8 @@ more complex, vendors want to perform more operations, such as: - Exposing a device to a container can require exposing more than one device node, mounting files from the runtime namespace, or hiding procfs entries. - Performing compatibility checks between the container and the device (e.g: Can - this container run on this device). -- Performing runtime-specific operations (e.g: VM vs Linux containers-based + this container run on this device?). +- Performing runtime-specific operations (e.g: VM vs Linux container-based runtimes). - Performing device-specific operations (e.g: scrubbing the memory of a GPU or reconfiguring an FPGA). @@ -46,7 +45,7 @@ write and maintain multiple plugins for different runtimes or even directly contribute vendor-specific code in the runtime. Additionally, runtimes don't uniformly expose a plugin system (or even expose a plugin system at all) leading to duplication of the functionality in higher-level abstractions (such as -Kubernetes device plugins). +[Kubernetes device plugins](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)). ## How does CDI work? @@ -66,7 +65,7 @@ For CDI to work the following needs to be done: ### CRI-O configuration In CRI-O CDI support is enabled by default. It is configured with the default -`/etc/cdi, /var/run/cdi` CDI directory locations. Therefore you can start using +`/etc/cdi, /var/run/cdi` CDI directory locations. Therefore, you can start using CDI simply by dropping CDI configuration files in either of those directories, static configuration into `/etc/cdi` and dynamically updated one into `/var/run/cdi`. If you are unsure of the configured directories you can run this diff --git a/SPEC.md b/SPEC.md index c0b5832..e3c05d5 100644 --- a/SPEC.md +++ b/SPEC.md @@ -3,8 +3,8 @@ - [Version](#version) - [Overview](#overview) - [General considerations](#general-considerations) -- [CDI JSON Specification](#well-known-error-codes) -- [CDI CLI Specification](#well-known-error-codes) +- [CDI JSON Specification](#cdi-json-specification) +- [Error Handling](#error-handling) ## Version @@ -72,7 +72,7 @@ For the purposes of this proposal, we define the following terms: - _container runtime_ which refers to the higher level component users tend to interact with for managing containers. It may also include lower level components that implement management of containers and pods (sets of containers). e.g: docker, podman, ... - _container runtime interface integration_ which refers to a server that implements the Container Runtime Interface (CRI) services, e.g: containerd+cri, cri-o, ... -The key words "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may" and "optional" are used as specified in [RFC 2119][rfc-2119]. +The keywords "must", "must not", "required", "shall", "shall not", "should", "should not", "recommended", "may" and "optional" are used as specified in [RFC 2119][rfc-2119]. [rfc-2119]: https://www.ietf.org/rfc/rfc2119.txt @@ -186,11 +186,11 @@ Note: For a CDI file to be valid, at least one entry must be specified in this a #### OCI Edits -The `containerEdits` field describes edits to be made to the OCI specification. Currently the following kinds of edits can be made to the OCI specification: `env`, `devices`, `mounts` and `hooks`. +The `containerEdits` field describes edits to be made to the OCI specification. Currently, the following kinds of edits can be made to the OCI specification: `env`, `devices`, `mounts` and `hooks`. The `containerEdits` field is referenced in two places in the specification: * At the device level, where the edits MUST only be made if the matching device is requested by the container runtime user. - * At the container level, where the edits MUST be made if any of the of the device defined in the `devices` field are requested. + * At the container level, where the edits MUST be made if any of the device defined in the `devices` field are requested. The `containerEdits` field has the following definition: @@ -223,11 +223,11 @@ The `containerEdits` field has the following definition: ## Error Handling * Kind requested is not present in any CDI file. - Container runtimes should surface an error when a non existent kind is requested. + Container runtimes should surface an error when a non-existent kind is requested. * Device (not device node) Requested does not exist. Container runtimes should surface this error when a non existent device is requested. * "Resource" does not exist (e.g: Mount, Hook, ...). - Container runtimes should surface this error when a non existent "resource" is requested (e.g: at "run" time). - This is because a resource does not need to exist when the spec is written but it needs to exist when the container is created. + Container runtimes should surface this error when a non-existent "resource" is requested (e.g: at "run" time). + This is because a resource does not need to exist when the spec is written, but it needs to exist when the container is created. * Hook fails to execute. Container runtimes should surface an error when hooks fails to execute.