Merge pull request #648 from swagatbora90/spelling-fix

Fix typo in getting-started doc

Author: swagatbora90

docs/getting-started.md

@@ -28,7 +28,7 @@ You need to have the following things in order to use firecracker-containerd:
   [ "$(uname) $(uname -m)" = "Linux x86_64" ] \
     || err="ERROR: your system is not Linux x86_64."; \
   [ -r /dev/kvm ] && [ -w /dev/kvm ] \
-    || err="$err\nERROR: /dev/kvm is innaccessible."; \
+    || err="$err\nERROR: /dev/kvm is inaccessible."; \
   (( $(uname -r | cut -d. -f1)*1000 + $(uname -r | cut -d. -f2) >= 4014 )) \
     || err="$err\nERROR: your kernel version ($(uname -r)) is too old."; \
   dmesg | grep -i "hypervisor detected" \
@@ -322,7 +322,7 @@ CNI-configured networks offer the quickest way to get VMs up and running with
 connectivity between MicroVMs and to external networks. Setting one up requires
 a few extra steps in addition to the above Setup steps.
 
-Production deployments should be sure to choose a network configuration suitale
+Production deployments should be sure to choose a network configuration suitable
 to the specifics of the environment and workloads being hosting, with particular
 attention being given to network isolation between tasks.
 

docs/host-file-isolation.md

@@ -128,7 +128,7 @@ Linux provides different capabilities for preventing mutation to files:
   sealing enforces stronger permissions preventing modification, truncation,
   growth or changes in the permission set.
 
-Firecracker also provides some capabilitie:
+Firecracker also provides some capabilities:
 
 * Attaching the device as read-only - The emulated device visible to the microVM
   is presented as read-only, and the Firecracker VMM should prevent

docs/logging.md

@@ -1,4 +1,4 @@
-## Logging Congiguration
+## Logging Configuration
 --
 
 firecracker-containerd allows for users to specify per application/library
@@ -31,7 +31,7 @@ firecracker-runtime.json file.
 | firecracker:debug              | Most verbose log level for firecracker                                          |
 | firecracker:output             | Logs Firecracker's stdout and stderr. Can be used with other firecracker levels |
 | firecracker-go-sdk:error       | Logs any errors information in firecracker-go-sdk                               |
-| firecracker-go-sdk:warning     | Logs any errors or warnings in firracker-go-sdk                                 |
+| firecracker-go-sdk:warning     | Logs any errors or warnings in firecracker-go-sdk                               |
 | firecracker-go-sdk:info        | Logs any errors, warnings, or infos in firecracker-go-sdk                       |
 | firecracker-go-sdk:debug       | Most verbose logging for firecracker-go-sdk                                     |
 | firecracker-containerd:error   | Logs any error information during the container/vm lifecycle                    |

docs/shim-design.md

@@ -263,7 +263,7 @@ The proposed solution is to
 13. **If there IS already a shim managing this microVM**, then the new shim process will tell containerd about the pre-existing shim, to which any further requests should be sent
 14. **If there IS already a shim managing this microVM**, then the new shim can exit as the pre-existing one will handle further requests
 15. **If there IS already a shim managing this microVM**, the pre-existing shim will receive the incoming CreateTaskRequest from containerd
-16. **If there IS already a shim managing this microVM**, the pre-exisiting shim will forward the CreateTaskRequest to the Guest Agent, which will create the container and return a response
+16. **If there IS already a shim managing this microVM**, the pre-existing shim will forward the CreateTaskRequest to the Guest Agent, which will create the container and return a response
 17. **If there IS already a shim managing this microVM**, the pre-existing shim will forward the response back to containerd
 18. The final CreateTaskResponse is returned back to the orchestrator