Fix links and non-inclusive words

Removed storage.md documentation as none of it is relevant anymore Signed-off-by: fossedihelm <fossedihelm@gmail.com>
lyarwood · Nov 18, 2021 · 3ab6912 · 3ab6912
1 parent ea34ce1
commit 3ab6912
Show file tree

Hide file tree

Showing 10 changed files with 23 additions and 128 deletions.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -109,7 +109,7 @@ Please have a look at our [membership guidelines](https://github.com/kubevirt/co
   * [User Guide - Kubernetes](https://kubernetes.io/docs/user-guide/)
 * Details
   * [Declarative Management of Kubernetes Objects Using Configuration Files - Kubernetes](https://kubernetes.io/docs/concepts/tools/kubectl/object-management-using-declarative-config/)
-  * [Kubernetes Architecture](https://github.com/kubernetes/community/blob/main/contributors/design-proposals/architecture/architecture.md)
+  * [Kubernetes Architecture](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/architecture/architecture.md)
 
 ## Additional Topics
 

diff --git a/docs/devel/networking.md b/docs/devel/networking.md
@@ -192,7 +192,7 @@ stage, will look like:
 
 Once the VM is booted, libvirt will consume the interface xml definition and
 create a tap device - named after the `target` parameter. That tap device will
-be attached to the in-pod bridge as its port, and the tap device's MAC address,
+be attached to the in-pod bridge, and the tap device's MAC address,
 and link MTU will be configured according to the values set in the domain xml.
 
 Finally, and depending if the pod networking interface had configured IP

diff --git a/docs/devel/olm-integration.md b/docs/devel/olm-integration.md
@@ -148,10 +148,10 @@ Travis cares for this on every release.
 - check that the marketplace operator is running in the `marketplace` namespace
 ## Sources
 
-[CSV description](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/Documentation/design/building-your-csv.md)  
-[CSV required fields](https://github.com/operator-framework/community-operators/blob/master/docs/required-fields.md)  
+[CSV description](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/design/building-your-csv.md)  
+[CSV required fields](https://github.com/operator-framework/community-operators/blob/master/docs/packaging-required-fields.md)  
 [Publish bundles](https://github.com/operator-framework/community-operators/blob/master/docs/testing-operators.md)  
-[Install OLM](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/Documentation/install/install.md)  
+[Install OLM](https://github.com/operator-framework/operator-lifecycle-manager/blob/master/doc/install/install.md)  
 [Install and use Marketplace](https://github.com/operator-framework/operator-marketplace)  
 
 ## Important

diff --git a/docs/devel/storage.md b/docs/devel/storage.md
diff --git a/docs/env-providers.md b/docs/env-providers.md
@@ -27,13 +27,13 @@ Usage:
 
 ```bash
 export KUBEVIRT_PROVIDER=k8s-1.13.3 # choose this provider
-export KUBEVIRT_NUM_NODES=3 # master + two nodes
+export KUBEVIRT_NUM_NODES=3 # control-plane + two nodes
 make cluster-up
 ```
 
 ## Local
 
-Allows provisioning a single-master k8s cluster based on latest upstream k8s
+Allows provisioning a single-control-plane k8s cluster based on latest upstream k8s
 code.
 
 Requires:

diff --git a/docs/getting-started.md b/docs/getting-started.md
@@ -78,13 +78,13 @@ make cluster-up
 make cluster-sync
 ```
 
-This will create a virtual machine called `node01` which acts as node and master. To create
-more nodes which will register themselves on master, you can use the
-`KUBEVIRT_NUM_NODES` environment variable. This would create a master and one
+This will create a virtual machine called `node01` which acts as node and control-plane. To create
+more nodes which will register themselves on control-plane, you can use the
+`KUBEVIRT_NUM_NODES` environment variable. This would create a control-plane and one
 node:
 
 ```bash
-export KUBEVIRT_NUM_NODES=2 # schedulable master + one additional node
+export KUBEVIRT_NUM_NODES=2 # schedulable control-plane + one additional node
 make cluster-up
 ```
 
@@ -149,8 +149,8 @@ You can get the names from following command:
 
 ```bash
 # cluster-up/kubectl.sh get nodes
-NAME     STATUS   ROLES           AGE   VERSION
-node01   Ready    master,worker   13s   v1.18.3
+NAME     STATUS   ROLES                   AGE   VERSION
+node01   Ready    control-plane,worker    13s   v1.18.3
 ```
 
 Then you can execute the following command to access the node:
@@ -241,7 +241,7 @@ Finally start a VMI called `vmi-ephemeral`:
     ./cluster-up/kubectl.sh -n kubevirt get pods
 ```
 
-This will start a VMI on master or one of the running nodes with a macvtap and a
+This will start a VMI on control-plane or one of the running nodes with a macvtap and a
 tap networking device attached.
 
 #### Example

diff --git a/docs/kubernetes-compatibility.md b/docs/kubernetes-compatibility.md
@@ -18,11 +18,11 @@ KubeVirt release v0.1 is cut. At that point in time the latest Kubernetes
 version is v1.3. This means KubeVirt v0.1 will forever be compatible with
 Kubernetes v1.3, v1.2, and v1.1.
 
-## KubeVirt Master
+## KubeVirt Main
 
-KubeVirt master always follows the latest 3 Kubernetes releases. If a new
+KubeVirt main always follows the latest 3 Kubernetes releases. If a new
 Kubernetes v1.4 release is cut, that means support for v1.1 will be dropped
-for KubeVirt master.
+for KubeVirt main.
 
 Note that this support for the latest Kubernetes releases doesn't happen
 immediately. There is a period of time, usually a few weeks, where the new
@@ -32,11 +32,11 @@ KubeVirt release is cut.
 
 ## Old KubeVirt Release
 
-KubeVirt master supports Kubernetes releases v1.4, v1.3, and v1.2. However, the
+KubeVirt main supports Kubernetes releases v1.4, v1.3, and v1.2. However, the
 KubeVirt v0.1 release was cut when the latest Kubernetes release was v1.3.
 
 This means that KubeVirt v0.1 supports Kubernetes v1.3, v1.2, v1.1 while
-KubeVirt master is tracking support for Kubernetes v1.4, v1.3, v1.2.
+KubeVirt main is tracking support for Kubernetes v1.4, v1.3, v1.2.
 
 # Support Exceptions
 

diff --git a/docs/reviewer-guide.md b/docs/reviewer-guide.md
@@ -25,7 +25,7 @@ Make a few passes over the code you want to review.
 
 ## Pull Request structure
 
-* It's preferred that authors rebase on main instead of merging main into their PRs.
+* It's preferred that authors rebase on main instead of merging the main branch into their PRs.
 * We merge PRs into our branches.
 * Commits in a PR should make sense: Ask people to squash commits like "Fix reviewer comments", "wip", "addition", ...
 

diff --git a/docs/sriov.md b/docs/sriov.md
@@ -144,7 +144,7 @@ deploy from KubeVirt sources though.
 
 In the following example, we configure the cluster using `local` provider which
 is part of kubevirt/kubevirt repo. Please consult
-[documentation](https://github.com/kubevirt/kubevirt/blob/master/cluster-up/cluster/local/README.md)
+[documentation](https://github.com/kubevirt/kubevirt/blob/main/cluster-up/cluster/local/README.md)
 for general information on setting up a host using the `local` provider.
 
 The `local` provider does not install default CNI plugins like `loopback`. So
@@ -272,7 +272,7 @@ make cluster-sync
 If all goes well, you should be able to post a VMI spec referring to the SR-IOV
 multus network and get a PCI device allocated to virt-launcher and passed
 through into qemu. Please consult
-[the VMI spec example](https://github.com/kubevirt/kubevirt/blob/master/examples/vmi-sriov.yaml).
+[the VMI spec example](https://github.com/kubevirt/kubevirt/blob/main/examples/vmi-sriov.yaml).
 
 As long as the VMI spec `networks` section refers to the proper
 `NetworkAttachmentDefinition` that describes a SR-IOV network, you should be

diff --git a/docs/update-go-version.md b/docs/update-go-version.md
@@ -53,7 +53,7 @@ In addition, [go rules for bazel](https://github.com/bazelbuild/rules_go) have t
     ```
 * Visit [Bazel's releases page](https://github.com/bazelbuild/rules_go/releases) and check whether the current Bazel version supports the new Go version.
   * If it is not supported, replace the `io_bazel_rules_go` definition with the one provided in Bazel's page.
-* Use [project-infra's uploader tool](https://github.com/kubevirt/project-infra/blob/main/plugins/cmd/uploader/README.md) to upload new dependencies to dependency mirror.
+* Use [project-infra's uploader tool](https://github.com/kubevirt/project-infra/blob/main/robots/cmd/uploader/README.md) to upload new dependencies to dependency mirror.