diff --git a/docs/conformance.md b/docs/conformance.md index cf71b64bf3d9..85d3811ddc69 100644 --- a/docs/conformance.md +++ b/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 diff --git a/docs/container-empty-disks.md b/docs/container-empty-disks.md index 574ceba985cb..323983e3bf11 100644 --- a/docs/container-empty-disks.md +++ b/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 diff --git a/docs/devel/guest-os-info.md b/docs/devel/guest-os-info.md index ec41a0dbda02..14b1d65f12fc 100644 --- a/docs/devel/guest-os-info.md +++ b/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) diff --git a/docs/devel/olm-integration.md b/docs/devel/olm-integration.md index 24dd5a2ea5eb..579d6bbf38cf 100644 --- a/docs/devel/olm-integration.md +++ b/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 diff --git a/docs/devel/virtual-machine.md b/docs/devel/virtual-machine.md index 83867f8feab8..9f3615774ced 100644 --- a/docs/devel/virtual-machine.md +++ b/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,8 +71,8 @@ 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. @@ -80,7 +80,7 @@ The VirtualMachine object is a CRD, which implies that Kubernetes provides the API automatically. The API is located at the path ```text -/apis/kubevirt.io/v1alpha2/virtualmachine/ +/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 diff --git a/docs/filesystem-pv-disks.md b/docs/filesystem-pv-disks.md index 07dcdd2fef8e..3c1e7e25ea79 100644 --- a/docs/filesystem-pv-disks.md +++ b/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. diff --git a/docs/getting-started.md b/docs/getting-started.md index f4e324e1118c..a379cc2340c0 100644 --- a/docs/getting-started.md +++ b/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. diff --git a/docs/gosec.md b/docs/gosec.md index f426b4dff126..e36e4fa1a07a 100644 --- a/docs/gosec.md +++ b/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 diff --git a/docs/guestfs.md b/docs/guestfs.md index 7f4316df6b5f..7138fa3a26c1 100644 --- a/docs/guestfs.md +++ b/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 diff --git a/docs/libvirt-pod-networking.md b/docs/libvirt-pod-networking.md index 164d39b22dab..6ff37de8cbde 100644 --- a/docs/libvirt-pod-networking.md +++ b/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, diff --git a/docs/localstorage-disks.md b/docs/localstorage-disks.md index 3e5690d35221..88c6af905d18 100644 --- a/docs/localstorage-disks.md +++ b/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. diff --git a/docs/release.md b/docs/release.md index 2d2803aaab16..e9fa2250a5f1 100644 --- a/docs/release.md +++ b/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 ` +issue can be flagged as a blocker through the use of the `/release-blocker ` 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``` diff --git a/docs/reviewer-guide.md b/docs/reviewer-guide.md index ae97e996d1f1..a08cecf726ce 100644 --- a/docs/reviewer-guide.md +++ b/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). diff --git a/docs/updates.md b/docs/updates.md index e06963b106fb..65d1cba52ae6 100644 --- a/docs/updates.md +++ b/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.