docs: Fix a bunch of typos and formatting

docs/README.md

@@ -21,7 +21,7 @@ therefore required. For best results, use this path:
 
 ### Project Components
 
- * virt-api: This component provides a HTTP RESTfull entrypoint to manage
+ * virt-api: This component provides a HTTP RESTful entrypoint to manage
    the virtual machines within the cluster.
  * virt-controller: This component manages the state of each VM within the
    Kubernetes cluster.

docs/architecture.md

@@ -49,7 +49,7 @@ to provide the new functionality:
 1. Additional types - so called 3rd party resources - are added to the
    Kubernetes API
 2. Additional controllers for cluster wide logic associated with this new types
-3- Additional daemons for node specific logic associated with new types
+3. Additional daemons for node specific logic associated with new types
 
 Once all three steps have been completed, you are able to
 
@@ -89,4 +89,3 @@ communicate with Kubernetes and where the additional types are stored:
 KubeVirt is deployed on top of a Kubernetes cluster.
 This means that you can continue to run your Kubernetes-native workloads next
 to the VMs managed through KubeVirt.
-

docs/components.md

@@ -25,7 +25,7 @@ KubeVirt consists of a set of services:
 
 The following flow illustrates the communication flow between several
 (not all) components present in KubeVirt.
-In general the commnuication pattern can be considered to be a
+In general the communication pattern can be considered to be a
 choreography, where all components act by themselves to realize the state
 provided by the `VM` objects.
 
@@ -61,12 +61,12 @@ DELETE /virtualmachines -> validate     |         |                       |
 there are _temporary workarounds_ in place to avoid bugs and address some
 other stuff.
 
-1. A client posts a new VM definition to the K8s API Server
+1. A client posts a new VM definition to the K8s API Server.
 2. The K8s API Server validates the input and creates a `VM` 3rd party
    resource (TPR) object.
 3. The `virt-controller` observes the creation of the new `VM` object
    and creates a corrsponding pod.
-4. Kubernetes is scheduling the pod on a host
+4. Kubernetes is scheduling the pod on a host.
 5. The `virt-controller` observes that a pod for the `VM` got started and
    updates the `nodeName` field in the`VM` object.
    Now that the `nodeName` is set, the responsibility transitions to the
@@ -76,7 +76,7 @@ other stuff.
 6. The `virt-handler` is using the _VM Specification_ and creates a
    corresponding domain using the local `libvirtd` instance.
 7. A client deletes the `VM` object through the `virt-api-server`.
-8. The `virt-handler` observes the deletion and turns off the domain. 
+8. The `virt-handler` observes the deletion and turns off the domain.
 
 ## `virt-api-server`
 
@@ -179,21 +179,21 @@ Investigations are still in progress.
 
 ###  Storage Controller
 
-Such a controller will not be part of KubeVirt itself. 
+Such a controller will not be part of KubeVirt itself.
 
 However KubeVirt might define a Storage TPR along side with a flow description which will allow such a controller seamless integration into KubeVirt.
 
-## Networking 
+## Networking
 
 We will try to leverage as much of Kubernetes networking plugin mechanisms (e.g. CNI).
 However, `virt-handler` may provide a plugin mechanism to allow network setup on a host, if the KubeVirt requirements do not fit into the Kubernetes storage scenarios.
 
-Since host side preparation of network interfaces may not be enought, a cluster-wide [Network Controller](###network-controller) can be used to prepare the newtork.
+Since host side preparation of network interfaces may not be enough, a cluster-wide [Network Controller](###network-controller) can be used to prepare the network.
 
 Investigations are still in progress.
 
 ## Network Controller
 
-Such a controller will not be part of KubeVirt itself. 
+Such a controller will not be part of KubeVirt itself.
 
 However KubeVirt might define a Networking TPR along side with a flow description which will allow such a controller seamless integration into KubeVirt.

docs/container-register-disks.md

@@ -1,4 +1,4 @@
-# Storing VM Disks in the Container Registery
+# Storing VM Disks in the Container Registry
 
 ## Motivation
 
@@ -41,7 +41,7 @@ Users want to attach a non-bootable disk to a VM preloaded with data. This data
 could consist of anything. It could be configuration data, rpms, or anything
 else a user might want to distribute with their VMs.
 
-## Implementation 
+## Implementation
 
 ### High Level Design
 
@@ -61,7 +61,7 @@ device consumable by libvirt.
 
 Example:
 ```
-cat << END > Dockerfile 
+cat << END > Dockerfile
 FROM kubevirt.io:disk
 ADD fedora25.qcow2 /disk
 END
@@ -103,5 +103,4 @@ a local file.
 The **v1** part of the RegistryDisk disk type represents the standard
 used during the virt-handler disk conversion process. As we gain more
 experience with this feature, we may want to adopt a new standard for how VM
-images are wrapped by a container while maintaining backwards compatibility. 
-
+images are wrapped by a container while maintaining backwards compatibility.

docs/direct-pv-disks.md

@@ -16,7 +16,7 @@ Volumes as a backing store for Virtual Machine disks.
 ### Use-case
 
 The primary use-case is to attach regular (writable) disks to Virtual Machines
-which are backed by Peristent Volumes.
+which are backed by Persistent Volumes.
 
 
 ## API

docs/glossary.md

@@ -3,9 +3,9 @@
 This document exists to to give the KubeVirt community a common language to
 work with when describing features and making design proposals. Some of the
 terms in this document do not actually exist in the current design yet, but
-are instead concepts the KubeVirt team is in the process of formulizing. As new
+are instead concepts the KubeVirt team is in the process of formalizing. As new
 concepts are introduced into the community, this document should be updated to
-reflect the continued evolvement of our common language. 
+reflect the continued evolution of our common language. 
 
 Terms for Items the KubeVirt community are still discussing are marked with the
 (WIP) tag.
@@ -98,7 +98,7 @@ A VirtualMachineConfig is a concept that allows users to post a representation
 of a VM into the cluster in a way that is de-coupled from start/stopping the VM.
 
 A user can post a VirtualMachineConfig and later choose to start a VM using that
-config.  This lets the config remain persistent between VM starts/stops. 
+config.  This lets the config remain persistent between VM starts/stops.
 
 ## VirtualMachineGroup aka VMG (WIP)
 
@@ -110,7 +110,7 @@ instances to match the desired number of cloned instances defined by the VMG.
 ## KubeVirt Cluster Node
 
 The underlying hardware KubeVirt is scheduling VMs on top of. Any node KubeVirt
-is capable of starting a VM on is considered a cluster node. 
+is capable of starting a VM on is considered a cluster node.
 
 ## KubeVirt Runtime
 
@@ -133,15 +133,15 @@ Method of storing and distributing VM disks with KubeVirt using the container
 registry.
 
 ## Domain
-Libvirt domain. `virt-handler` can derive a Domain XML out of a [VM Spec](#vm-specification-aka-vm-spec). 
+Libvirt domain. `virt-handler` can derive a Domain XML out of a [VM Spec](#vm-specification-aka-vm-spec).
 This is the host centric view of the cluster wide [VM Spec](#vm-specification-aka-vm-spec).
 
 ## Domain XML
 
 Configuration used to define a domain in Libvirt.  The VM spec is transformed
 into domain xml during VM creation on a cluster node. The Domain xml is used to
 communicate with Libvirt the information pertaining to how the VM should be
-launched. 
+launched.
 
 ## Third Party Resource aka TPR
 Kubernetes has an extensible API which allows extending its REST-API.
@@ -179,5 +179,3 @@ and other normal requests will not show the object until it is ready. So the
 fact that this works asynchronous is hidden from the user.
 
 https://kubernetes.io/docs/admin/extensible-admission-controllers/#what-are-initializers
-
-