docs: Fix typos and formatting

Tidy up docs by resolving spelling mistakes and fixing
bad formatting.

Fixes: kata-containers#487.

Signed-off-by: James O. D. Hunt <[email protected]>

Author: jodh-intel

Developer-Guide.md

@@ -33,7 +33,7 @@
 * [Run Kata Containers with Kubernetes](#run-kata-containers-with-kubernetes)
     * [Install a CRI implementation](#install-a-cri-implementation)
         * [CRI-O](#cri-o)
-        * [containerd with cri plugin](#containerd-with-cri-plugin)
+        * [containerd with CRI plugin](#containerd-with-cri-plugin)
     * [Install Kubernetes](#install-kubernetes)
         * [Configure for CRI-O](#configure-for-cri-o)
         * [Configure for containerd](#configure-for-containerd)
@@ -133,7 +133,7 @@ $ sudo sed -i 's/^\(initrd =.*\)/# \1/g' /etc/kata-containers/configuration.toml
 ```
 The rootfs image is created as shown in the [create a rootfs image](#create-a-rootfs-image) section.
 
-One of the `initrd` and `image` options in kata runtime config file **MUST** be set but **not both**.
+One of the `initrd` and `image` options in Kata runtime config file **MUST** be set but **not both**.
 The main difference between the options is that the size of `initrd`(10MB+) is significantly smaller than
 rootfs `image`(100MB+).
 
@@ -297,7 +297,7 @@ $ sudo rm -rf ${ROOTFS_DIR}
 $ cd $GOPATH/src/github.com/kata-containers/osbuilder/rootfs-builder
 $ script -fec 'sudo -E GOPATH=$GOPATH AGENT_INIT=yes USE_DOCKER=true SECCOMP=no ./rootfs.sh ${distro}'
 ```
-`AGENT_INIT` controls if the guest image uses kata agent as the guest `init` process. When you create an initrd image,
+`AGENT_INIT` controls if the guest image uses the Kata agent as the guest `init` process. When you create an initrd image,
 always set `AGENT_INIT` to `yes`. By default `seccomp` packages are not included in the initrd image. Set `SECCOMP` to `yes` to include them.
 
 You MUST choose one of `alpine`, `centos`, `clearlinux`, `euleros`, and `fedora` for `${distro}`.
@@ -348,8 +348,8 @@ $ curl -LOk ${kernel_url}
 $ tar -xf ${kernel_tar_file}
 $ mv .config "linux-${kernel_version}"
 $ pushd "linux-${kernel_version}"
-$ curl -L https://raw.githubusercontent.com/kata-containers/packaging/master/kernel/patches/4.19.x/0001-NO-UPSTREAM-9P-always-use-cached-inode-to-fill-in-v9.patch | patch -p1
-$ curl -L https://raw.githubusercontent.com/kata-containers/packaging/master/kernel/patches/4.19.x/0002-Compile-in-evged-always.patch | patch -p1
+$ curl -L https://raw.githubusercontent.com/kata-containers/packaging/master/kernel/patches/4.19.x/0003-NO-UPSTREAM-9P-always-use-cached-inode-to-fill-in-v9.patch | patch -p1
+$ curl -L https://raw.githubusercontent.com/kata-containers/packaging/master/kernel/patches/4.19.x/0004-Compile-in-evged-always.patch | patch -p1
 $ make ARCH=${kernel_dir} -j$(nproc)
 $ kata_kernel_dir="/usr/share/kata-containers"
 $ kata_vmlinuz="${kata_kernel_dir}/kata-vmlinuz-${kernel_version}.container"
@@ -371,7 +371,7 @@ When setting up Kata using a [packaged installation method](https://github.com/k
 
 ## Build a custom QEMU
 
-Your qemu directory need to be prepared with source code. Alternatively, you can use the [Kata containers QEMU](https://github.com/kata-containers/qemu/tree/master) and checkout the recommended branch:
+Your QEMU directory need to be prepared with source code. Alternatively, you can use the [Kata containers QEMU](https://github.com/kata-containers/qemu/tree/master) and checkout the recommended branch:
 
 ```
 $ go get -d github.com/kata-containers/qemu
@@ -397,7 +397,7 @@ $ sudo -E make install
 >
 > - You should only do this step if you are on aarch64/arm64.
 > - You should include [Eric Auger's latest PCDIMM/NVDIMM patches](https://patchwork.kernel.org/cover/10647305/) which are
->   under upstream review for supporting nvdimm on aarch64.
+>   under upstream review for supporting NVDIMM on aarch64.
 >
 You could build the custom `qemu-system-aarch64` as required with the following command:
 ```
@@ -508,7 +508,7 @@ Restart CRI-O to take changes into account
 $ sudo systemctl restart crio
 ```
 
-### containerd with cri plugin
+### containerd with CRI plugin
 
 If you select containerd with `cri` plugin, follow the "Getting Started for Developers"
 instructions [here](https://github.com/containerd/cri#getting-started-for-developers)
@@ -522,12 +522,11 @@ To customize containerd to select Kata Containers runtime, follow our
 
 Depending on what your needs are and what you expect to do with Kubernetes,
 please refer to the following
-[documentation](https://kubernetes.io/docs/setup/pick-right-solution/) to
-install it correctly.
+[documentation](https://kubernetes.io/docs/setup/) to install it correctly.
 
 Kubernetes talks with CRI implementations through a `container-runtime-endpoint`,
 also called CRI socket. This socket path is different depending on which CRI
-implementation you chose, and the kubelet service has to be updated accordingly.
+implementation you chose, and the Kubelet service has to be updated accordingly.
 
 ### Configure for CRI-O
 
@@ -549,8 +548,8 @@ documentation [here](https://github.com/kata-containers/documentation/blob/maste
 
 ## Run a Kubernetes pod with Kata Containers
 
-After you update your kubelet service based on the CRI implementation you
-are using, reload and restart kubelet. Then, start your cluster:
+After you update your Kubelet service based on the CRI implementation you
+are using, reload and restart Kubelet. Then, start your cluster:
 ```bash
 $ sudo systemctl daemon-reload
 $ sudo systemctl restart kubelet
@@ -564,11 +563,11 @@ $ sudo kubeadm init --skip-preflight-checks --cri-socket /run/containerd/contain
 $ export KUBECONFIG=/etc/kubernetes/admin.conf
 ```
 
-You can force kubelet to use Kata Containers by adding some _untrusted_
+You can force Kubelet to use Kata Containers by adding some `untrusted`
 annotation to your pod configuration. In our case, this ensures Kata
 Containers is the selected runtime to run the described workload.
 
-_nginx-untrusted.yaml_
+`nginx-untrusted.yaml`
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -594,7 +593,7 @@ If you are unable to create a Kata Container first ensure you have
 before attempting to create a container. Then run the
 [`kata-collect-data.sh`](https://github.com/kata-containers/runtime/blob/master/data/kata-collect-data.sh.in)
 script and paste its output directly into a
-[github issue](https://github.com/kata-containers/kata-containers/issues/new).
+[GitHub issue](https://github.com/kata-containers/kata-containers/issues/new).
 
 > **Note:**
 >

Documentation-Requirements.md

@@ -53,7 +53,7 @@ the concept is referred to using a link).
 Important information that is not part of the main document flow should be
 added as a Note in bold with all content contained within a block quote:
 
-> **Note:** This is areally important point!
+> **Note:** This is a really important point!
 >
 > This particular note also spans multiple lines. The entire note should be
 > included inside the quoted block.
@@ -118,15 +118,15 @@ utility.
   in a *bash code block* with every command line prefixed with `$ ` to denote
   a shell prompt:
 
-  ```
+  <pre>
 
       ```bash
       $ echo "Hi - I am some bash code"
       $ sudo docker run -ti busybox true
       $ [ $? -eq 0 ] && echo "success"
       ```
 
-  ```
+  <pre>
 
 - If a command needs to be run as the `root` user, it must be run using
   `sudo(8)`.
@@ -142,15 +142,15 @@ utility.
 - In the unusual case that you need to display command *output*, use an
   unadorned code block (\`\`\`):
 
-  ```
+  <pre>
 
       The output of the `ls(1)` command is expected to be:
 
       ```
       ls: cannot access '/foo': No such file or directory
       ```
 
-  ```
+  <pre>
 
 - Long lines should not span across multiple lines by using the '`\`'
   continuation character.

Limitations.md

@@ -13,7 +13,7 @@
         * [docker run and shared memory](#docker-run-and-shared-memory)
         * [docker run and sysctl](#docker-run-and-sysctl)
     * [Docker daemon features](#docker-daemon-features)
-        * [selinux support](#selinux-support)
+        * [SELinux support](#selinux-support)
 * [Architectural limitations](#architectural-limitations)
     * [Networking limitations](#networking-limitations)
         * [Support for joining an existing VM network](#support-for-joining-an-existing-vm-network)
@@ -64,10 +64,10 @@ spec and the non-standard extensions provided by `runc`.
 
 # Scope
 
-Each known limitation is captured in a separate github issue that contains
+Each known limitation is captured in a separate GitHub issue that contains
 detailed information about the issue. These issues are tagged with the
 `limitation` label. This document is a curated summary of important known
-limitations and provides links to the relevant github issues.
+limitations and provides links to the relevant GitHub issues.
 
 The following link shows the latest list of limitations:
 
@@ -76,7 +76,7 @@ The following link shows the latest list of limitations:
 # Contributing
 
 If you would like to work on resolving a limitation, please refer to the
-[contributers guide](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md).
+[contributors guide](https://github.com/kata-containers/community/blob/master/CONTRIBUTING.md).
 If you wish to raise an issue for a new limitation, either
 [raise an issue directly on the runtime](https://github.com/kata-containers/runtime/issues/new)
 or see the
@@ -136,7 +136,7 @@ these commands is potentially challenging.
 See issue https://github.com/clearcontainers/runtime/issues/341 and [the constraints challenge](#the-constraints-challenge) for more information.
 
 For CPUs resource management see
-[cpu-constraints](design/cpu-constraints.md).
+[CPU constraints](design/cpu-constraints.md).
 
 ### docker run and shared memory
 
@@ -156,10 +156,10 @@ See issue https://github.com/kata-containers/runtime/issues/185 for more informa
 ## Docker daemon features
 
 Some features enabled or implemented via the
-[dockerd daemon](https://docs.docker.com/config/daemon/) configuration are not yet
+[`dockerd` daemon](https://docs.docker.com/config/daemon/) configuration are not yet
 implemented.
 
-### selinux support
+### SELinux support
 
 The `dockerd` configuration option `"selinux-enabled": true` is not presently implemented
 in Kata Containers. Enabling this option causes an OCI runtime error.
@@ -168,7 +168,7 @@ See issue https://github.com/kata-containers/runtime/issues/784 for more informa
 
 The consequence of this is that the [Docker --security-opt is only partially supported](#docker---security-opt-option-partially-supported).
 
-Kubernetes [selinux labels](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#assign-selinux-labels-to-a-container) will also not be applied.
+Kubernetes [SELinux labels](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#assign-selinux-labels-to-a-container) will also not be applied.
 
 # Architectural limitations
 
@@ -244,7 +244,7 @@ Note: The `--security-opt apparmor=your_profile` is not yet supported. See https
 
 ## The constraints challenge
 
-Applying resource constraints such as cgroup, cpu, memory, and storage to a workload is not always straightforward with a VM based system. A Kata Container runs in an isolated environment inside a virtual machine. This, coupled with the architecture of Kata Containers, offers many more possibilities than are available to traditional Linux containers due to the various layers and contexts.
+Applying resource constraints such as cgroup, CPU, memory, and storage to a workload is not always straightforward with a VM based system. A Kata Container runs in an isolated environment inside a virtual machine. This, coupled with the architecture of Kata Containers, offers many more possibilities than are available to traditional Linux containers due to the various layers and contexts.
 
 In some cases it might be necessary to apply the constraints to multiple levels. In other cases, the hardware isolated VM provides equivalent functionality to the the requested constraint.
 

Release-Checklist.md

@@ -2,7 +2,7 @@
 
 This document lists the tasks required to create a Kata Release.
 
-It should be pasted directly into a github issue and each item checked off as it is completed.
+It should be pasted directly into a GitHub issue and each item checked off as it is completed.
 
 - [ ] Raise PRs to update the `VERSION` file in the following repositories:
    - [ ] [agent][agent]
@@ -32,17 +32,17 @@ It should be pasted directly into a github issue and each item checked off as it
    - [ ] [image][image]
    - [ ] [initrd][initrd]
    - [ ] [proxy][proxy]
-   - [ ] [qemu-lite][qemu-lite]
+   - [ ] [`qemu-lite`][qemu-lite]
    - [ ] [runtime][runtime]
    - [ ] [shim][shim]
    - [ ] [throttler][throttler]
 
 - [ ] Generate snap packages based on `HEAD`
    - [ ] Push snap packages via snapcraft tool
-   - [ ] Pubish snap packages in the snapcraft store
+   - [ ] Publish snap packages in the snapcraft store
 
 - [ ] Installation tests (must be done for major releases):
-  - [ ] Centos
+  - [ ] CentOS
   - [ ] Fedora
   - [ ] Ubuntu
 

Stable-Branch-Strategy.md

@@ -17,7 +17,7 @@ providing only bug and security fixes.
 Kata Containers will maintain two stable release branches in addition to the master branch.
 Once a new MAJOR or MINOR release is created from master, a new stable branch is created for
 the prior MAJOR or MINOR release and the older stable branch is no longer maintained. End of
-maintainence for a branch is announced on the Kata Containers mailing list.  Users can determine
+maintenance for a branch is announced on the Kata Containers mailing list.  Users can determine
 the version currently installed by running `kata-runtime kata-env`. It is recommended to use the
 latest stable branch available.
 
@@ -81,7 +81,7 @@ stable and master. While this is not in place currently, it should be considered
 ### Patch releases
 
 Releases are normally made every other week for patch releases, which include a GitHub release as
-well as binary packages. These patch releases are made for both stable branches, and a 'release candidate'
+well as binary packages. These patch releases are made for both stable branches, and a "release candidate"
 for the next `MAJOR` or `MINOR` is created from master. If there are no changes across all the repositories, no
 release is created and an announcement is made on the developer mailing list to highlight this.
 If a release is being made, each repository is tagged for this release, regardless
@@ -103,8 +103,8 @@ Kata guarantees compatibility between components that are within one minor relea
 
 This is critical for dependencies which cross between host (runtime, shim, proxy) and
 the guest (hypervisor, rootfs and agent).  For example, consider a cluster with a long-running
-deployment, workload-never-dies, all on kata version 1.1.3 components. If the operator updates
+deployment, workload-never-dies, all on Kata version 1.1.3 components. If the operator updates
 the Kata components to the next new minor release (i.e. 1.2.0), we need to guarantee that the 1.2.0
 runtime still communicates with 1.1.3 agent within workload-never-dies.
 
-Handling live-update is out of the scope of this document. See this [kata-runtime issue](https://github.com/kata-containers/runtime/issues/492) for details.
+Handling live-update is out of the scope of this document. See this [`kata-runtime` issue](https://github.com/kata-containers/runtime/issues/492) for details.

Upgrading.md

@@ -157,15 +157,15 @@ new package versions are published.
 
 The `kata-linux-container` package contains a Linux\* kernel based on the
 latest vanilla version of the
-[longterm kernel](https://www.kernel.org/)
+[long-term kernel](https://www.kernel.org/)
 plus a small number of
 [patches](https://github.com/kata-containers/packaging/tree/master/kernel).
 
 The `Longterm` branch is only updated with
 [important bug fixes](https://www.kernel.org/category/releases.html)
 meaning this package is only updated when necessary.
 
-The guest kernel package is updated when a new longterm kernel is released
+The guest kernel package is updated when a new long-term kernel is released
 and when any patch updates are required.
 
 ### Image