fix some type on doc

Signed-off-by: tgfree <[email protected]>

docs/conformance.md

@@ -56,7 +56,7 @@ Failed: 0
 Skipped: 579
 ```
 
-## Executing conformace tests in the development environment
+## Executing conformance tests in the development environment
 
 ```bash
 make conformance

docs/container-empty-disks.md

@@ -5,7 +5,7 @@
 KubeVirt in combination with use-cases like the cluster-autoscaler can be used
 to scale and provision vm pools. With the VirtualMachineInstanceReplicaSet and
 cloud-init stateless pools can be instantiated and provisioned.
-Many of the used cloud images for these use-cases are bootet with small disks
+Many of the used cloud images for these use-cases are booted with small disks
 with no additional free space, and/or run in read-only mode. A common pattern
 to store temporary data which should survive restarts or temporary data which
 is too big to fit in memory on temporary disks. The `emptyDir` in k8s provides

docs/devel/guest-os-info.md

@@ -12,17 +12,17 @@ metadata:
 The ``kubevirt.io/os`` label is based on the short OS identifier from [libosinfo](https://libosinfo.org/).
 The following Short IDs are currently supported:
 
-| Short ID | Name | Version | Family | ID |
-| --- | --- | --- | --- | --- |
-| **fedora26** | Fedora 26 | 26 | linux | http://fedoraproject.org/fedora/26 |
-| **fedora27** | Fedora 27 | 27 | linux | http://fedoraproject.org/fedora/27 |
-| **rhel7.0** | Red Hat Enterprise Linux 7.0 | 7.0 | linux | http://redhat.com/rhel/7.0 |
-| **rhel7.1** | Red Hat Enterprise Linux 7.1 | 7.1 | linux | http://redhat.com/rhel/7.1 |
-| **rhel7.2** | Red Hat Enterprise Linux 7.2 | 7.2 | linux | http://redhat.com/rhel/7.2 |
-| **rhel7.3** | Red Hat Enterprise Linux 7.3 | 7.3 | linux | http://redhat.com/rhel/7.3 |
-| **rhel7.4** | Red Hat Enterprise Linux 7.4 | 7.4 | linux | http://redhat.com/rhel/7.4 |
-| **win2k12r2** | Microsoft Windows Server 2012 R2 | 6.3 | winnt | http://microsoft.com/win/2k12r2 |
-| **win2k16** | Microsoft Windows Server 2016 | 1709 | winnt | http://microsoft.com/win/2k16 |
+| Short ID      | Name                             | Version | Family | ID                                 |
+|---------------|----------------------------------|---------|--------|------------------------------------|
+| **fedora26**  | Fedora 26                        | 26      | linux  | http://fedoraproject.org/fedora/26 |
+| **fedora27**  | Fedora 27                        | 27      | linux  | http://fedoraproject.org/fedora/27 |
+| **rhel7.0**   | Red Hat Enterprise Linux 7.0     | 7.0     | linux  | http://redhat.com/rhel/7.0         |
+| **rhel7.1**   | Red Hat Enterprise Linux 7.1     | 7.1     | linux  | http://redhat.com/rhel/7.1         |
+| **rhel7.2**   | Red Hat Enterprise Linux 7.2     | 7.2     | linux  | http://redhat.com/rhel/7.2         |
+| **rhel7.3**   | Red Hat Enterprise Linux 7.3     | 7.3     | linux  | http://redhat.com/rhel/7.3         |
+| **rhel7.4**   | Red Hat Enterprise Linux 7.4     | 7.4     | linux  | http://redhat.com/rhel/7.4         |
+| **win2k12r2** | Microsoft Windows Server 2012 R2 | 6.3     | winnt  | http://microsoft.com/win/2k12r2    |
+| **win2k16**   | Microsoft Windows Server 2016    | 1709    | winnt  | http://microsoft.com/win/2k16      |
 
 For the updated list please refer to kubeVirt user guide - [Guest Operating System Information](https://kubevirt.gitbooks.io/user-guide/guest-os-info.html)
 

docs/devel/olm-integration.md

@@ -39,7 +39,7 @@ CRDs:
 
 - InstallPlan:  
   calculated list of resources to be created in order to automatically install/upgrade a CSV
-  created and insalled by the Catalog Operator, needs manual or automatic approval
+  created and installed by the Catalog Operator, needs manual or automatic approval
 
 ### Operator Marketplace
 

docs/devel/virtual-machine.md

@@ -17,7 +17,7 @@ designed to work in tandem with the VirtualMachine and provides the
 configuration and status for running virtual machines.
 
 VirtualMachine is a Kubernetes [custom resource definition](https://kubernetes.io/docs/concepts/api-extension/custom-resources/), which
-allows for using the Kubernetes machanisms for storing the objects and
+allows for using the Kubernetes mechanisms for storing the objects and
 exposing it through the API.
 
 ## What it does and how to use it
@@ -71,16 +71,16 @@ kubectl delete virtualmachine myvm --cascade=false
 ### The REST API
 
 The kubectl is a handy tool that provides handy access to cluster, when you sit
-at the console. But, when you are writting an external application that
-needs to access the cluster programaticaly, it is better to have a API endpoint.
+at the console. But, when you are writing an external application that
+needs to access the cluster programmatically, it is better to have a API endpoint.
 Thats where the Kubernetes REST API endpoint comes right in. Kubernetes provides
 for its users the native REST API, which is easily extendable and in one place.
 
 The VirtualMachine object is a CRD, which implies that Kubernetes
 provides the API automatically. The API is located at the path
 
 ```text
-<your-api-server-adress>/apis/kubevirt.io/v1alpha2/virtualmachine/
+<your-api-server-address>/apis/kubevirt.io/v1alpha2/virtualmachine/
 ```
 
 and you can do typical REST manipulation, you would expect. All CRUD is
@@ -182,7 +182,7 @@ spec:
 ```
 
 It is easy to see that it is exactly the same as [VirtualMachineInstance],
-but it does not have a `kind` and `apiVersion`. These are implicitely added.
+but it does not have a `kind` and `apiVersion`. These are implicitly added.
 
 Thus for the complete list of supported fields in the spec.template please refer
 to the [VirtualMachineInstance] documentation.
@@ -234,11 +234,11 @@ status:
 
 Linking the created VirtualMachine to its parent VirtualMachine pose
 a challenge. Using the same name is only part of the solution. To find the
-parent VirtualMachine programatically in the Kubernetes, the OwnerReference
+parent VirtualMachine programmatically in the Kubernetes, the OwnerReference
 is used. As described in the
 [design document](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/controller-ref.md),
 the OwnerReference lives in the metadata section of the object and is created
-automaticaly. Example:
+automatically. Example:
 
 ```YAML
 apiVersion: kubevirt.io/v1alpha2
@@ -320,7 +320,7 @@ VirtualMachineInstance and show combined status.
 
 The controller is designed to be a standalone service running in its own pod.
 Since the whole KubeVirt is designed to be modular, this approach allows for
-a more flexbility and less codebase in the core. Moreover it can be scaled
+a more flexibility and less codebase in the core. Moreover it can be scaled
 up separately if the need arise.
 
 [VirtualMachineInstance]: https://kubevirt.github.io/api-reference/master/definitions.html#_v1_virtualmachine

docs/filesystem-pv-disks.md

@@ -77,7 +77,7 @@ VMI.
 
 The system needs to know if the referenced volume needs to be treated as a
 block or file-system volume.
-Since Kubernetes 1.9 this information can be infered from the existing PV
+Since Kubernetes 1.9 this information can be inferred from the existing PV
 metadata.
 
 

docs/getting-started.md

@@ -125,7 +125,7 @@ have a completely fresh cluster to play with.
 #### Sync specific components
 
 **Note:** The following is meant for allowing faster iteration on small changes to components that support it.
-Not every component is that simply exchangable without a full re-deploy. Always test with the final SHA based method in the end.
+Not every component is that simply exchangeable without a full re-deploy. Always test with the final SHA based method in the end.
 
 In situations where you just want to work on a single component and rollout updates
 without re-deploying the whole environment, you can tell kubevirt to deploy using tags.

docs/gosec.md

@@ -20,7 +20,7 @@ In extreme cases you can annotate the code with a special comment:
 This will instruct gosec to suppress the warning.
 The developer is encouraged to avoid this annotation whenever possible as this will **silence all warnings** in the line below the comment, even if the code changes and another, true positive issue is created because of that.
 
-### How to fix false positive warnnings
+### How to fix false positive warnings
 Define a new “safe” function that encapsulates the risky function or code
 The safe function name should give good indication on when this function should be used. Whenever possible, the function should validate in-code that the condition really applies.
 Annotate the call with a `//#nosec ` comment only within this unsafe function implementation

docs/guestfs.md

@@ -1,6 +1,6 @@
 # Usage of libguestfs-tools and virtctl guestfs
 
-[Libguestfs tools](https://libguestfs.org/) are a set of utilities for accessing and modifying VM disk images. The command `virtctl guestfs` helps to deploy an interactive container with the libguestfs-tools and the PVC attached to it. This command is particurarly useful if the users need to modify, inspect or debug VM disks on a PVC.
+[Libguestfs tools](https://libguestfs.org/) are a set of utilities for accessing and modifying VM disk images. The command `virtctl guestfs` helps to deploy an interactive container with the libguestfs-tools and the PVC attached to it. This command is particularly useful if the users need to modify, inspect or debug VM disks on a PVC.
 ```bash
 $ virtctl guestfs -h
 Create a pod with libguestfs-tools, mount the pvc and attach a shell to it. The pvc is mounted under the /disks directory inside the pod for filesystem-based pvcs, or as /dev/vda for block-based pvcs

docs/libvirt-pod-networking.md

@@ -83,7 +83,7 @@ The required steps to enable networking as described are:
    and configure libvirt to provide the remembered IP address to the VMI.
    Achieved by adding a DHCP host entry, which maps the vNIC MAC address to the
    remembered IP
-4. On VMI shutdown, delete all VMI interfaces. They can be infered by following
+4. On VMI shutdown, delete all VMI interfaces. They can be inferred by following
    the libvirt networks associated with the vNICs
 
 **Note:** The _new_ VMI interface can not be directly attached to the VMI,

docs/localstorage-disks.md

@@ -37,7 +37,7 @@ After PVC are bound the `CDI` can do its work and KubeVirt can start the actual
 5. `KubeVirt` sees the DV in phase `WaitForFirstConsumer`, so it creates an ephemeral pod (basically a virtlauncher pod
 without a VM payload and with `kubevirt.io/ephemeral-provisioning` annotation) only used to force PV provisioning 
 6. Kubernetes schedules the ephemeral pod, (the node selected meets all the VM requirements), pod requires 
- the same PVC as the VM so kubenertes has to provision and bind the PV to PVC on a correct node before the pod can be started
+ the same PVC as the VM so kubernetes has to provision and bind the PV to PVC on a correct node before the pod can be started
 7. `CDI` sees that PVC is Bound, changes DV status to "ImportScheduled" (or clone/upload), and tries to start worker pods
 8. `KubeVirt` sees DV status is `ImportScheduled`, it can terminate the ephemeral provisioning pod
 8. `CDI` does the Import, marks DV as `Succeeded`
@@ -66,7 +66,7 @@ Waiting for PVC fedora-dv upload pod to be ready...
 cannot upload to DataVolume in state WaitForFirstConsumer
 ```
 
-Current version of virtctl should immediatetly detect the problem and error. The older version will take all the time limit and finish with timeout.
+Current version of virtctl should immediately detect the problem and error. The older version will take all the time limit and finish with timeout.
 
 2. To bind the `PVC` create a consumer `POD`. With a `nodeSelector` to select a specific node ot without for a random node.
 

docs/release.md

@@ -102,7 +102,7 @@ git show v0.31.0-rc.0
 # Handling Release Blockers
 
 Release blockers can be set on issues and PRs by [approvers](https://github.com/kubevirt/kubevirt/blob/main/OWNERS_ALIASES) of the project. A PR or
-issue can be flaged as a blocker through the use of the `/release-blocker <branch>`
+issue can be flagged as a blocker through the use of the `/release-blocker <branch>`
 in a github comment.
 
 The KubeVirt release tool scans for blocker Issues/PRs and will not allow certain
@@ -112,7 +112,7 @@ for closed issues!**
 
 ## Release Blocker Criteria
 
-A release blocker is a critial bug, regression, or backwards incompatible change
+A release blocker is a critical bug, regression, or backwards incompatible change
 that must be addressed before the next official release is made. Only KubeVirt
 [approvers](https://github.com/kubevirt/kubevirt/blob/main/OWNERS_ALIASES) can set this label on a PR or Issue.
 
@@ -135,7 +135,7 @@ Issue/PR is closed.
 ```/release-blocker release-0.31```
 
 **Example: Canceling a release-blocker.** This will remove the signal that
-an Issue/PR is a blocker. This should only be done if the issue truely
+an Issue/PR is a blocker. This should only be done if the issue truly
 isn't a blocker.
 
 ```/release-blocker cancel release-0.31```

docs/reviewer-guide.md

@@ -62,4 +62,4 @@ The lowest bar for acceptable golang **coding standards** (anti-patterns, coding
 
 The lowest **testing bar** to pass:
 * New code requires new unit tests.
-* New fetures and bug fixes require at least on e2e test (the core case must be tested).
+* New features and bug fixes require at least on e2e test (the core case must be tested).

docs/updates.md

@@ -18,7 +18,7 @@ limited to anything that involves persistent connections to a control plane
 component.
 
 1. In-flight migrations will fail. The VMI will remain available, but the
-migration itself will fail due to a severed TLS connection occuring when
+migration itself will fail due to a severed TLS connection occurring when
 virt-handler updates.
 
 2. `virtctl console` and `virtctl vnc` connections will get dropped. This is
@@ -103,7 +103,7 @@ of new functionality.
 
 ### RBAC 
 
-Since during the update our controll plane will be briefly running both old and
+Since during the update our control plane will be briefly running both old and
 new versions, we have to ensure that RBAC permissions are available that allow
 both the old and new versions of components to operate at the same time.