Merge pull request #8232 from abhay-krishna/typo-fix

 📖 Clean up some typos and links in CAPI book

docs/book/src/clusterctl/developers.md

@@ -33,7 +33,7 @@ If you want to create a local artifact, follow these instructions:
 
 ### Build artifacts locally
 
-In order to build artifacts for the CAPI core provider, the kubeadm bootstrap provider, the kubeadm control plane provider and the docker infrastructure provider:
+In order to build artifacts for the CAPI core provider, the kubeadm bootstrap provider, the kubeadm control plane provider and the Docker infrastructure provider:
 
 ```bash
 make docker-build REGISTRY=gcr.io/k8s-staging-cluster-api PULL_POLICY=IfNotPresent
@@ -96,7 +96,7 @@ during your dev session.
 The above config file changes the location of the [overrides layer] folder thus ensuring
 you dev session isn't hijacked by other local artifacts.
 
-With the only exception of the docker provider, the local repository folder does not contain cluster templates,
+With the only exception of the Docker provider, the local repository folder does not contain cluster templates,
 so the `clusterctl generate cluster` command will fail.
 
 </aside>
@@ -126,11 +126,11 @@ please note that each `provider_repo` should have its own `clusterctl-settings.j
 ## Create a kind management cluster
 
 [kind] can provide a Kubernetes cluster to be used as a management cluster.
-See [Install and/or configure a kubernetes cluster] for more information.
+See [Install and/or configure a Kubernetes cluster] for more information.
 
 *Before* running clusterctl init, you must ensure all the required images are available in the kind cluster.
 
-This is always the case for images published in some image repository like docker hub or gcr.io, but it can't be
+This is always the case for images published in some image repository like Docker Hub or gcr.io, but it can't be
 the case for images built locally; in this case, you can use `kind load` to move the images built locally. e.g.
 
 ```bash
@@ -148,7 +148,7 @@ script.
 
 Optionally, you may want to check if the components are running properly. The
 exact components are dependent on which providers you have initialized. Below
-is an example output with the docker provider being installed.
+is an example output with the Docker provider being installed.
 
 ```bash
 kubectl get deploy -A | grep  "cap\|cert"
@@ -166,7 +166,7 @@ cert-manager                        cert-manager-webhook
 
 ## Additional Notes for the Docker Provider
 
-### Select the appropriate kubernetes version
+### Select the appropriate Kubernetes version
 
 When selecting the `--kubernetes-version`, ensure that the `kindest/node`
 image is available.
@@ -205,6 +205,6 @@ sed -i -e "s/server:.*/server: https:\/\/$(docker port capi-quickstart-lb 6443/t
 [kind]: https://kind.sigs.k8s.io/
 [providers repositories]: configuration.md#provider-repositories
 [overrides layer]: configuration.md#overrides-layer
-[Install and/or configure a kubernetes cluster]: ../user/quick-start.md#install-andor-configure-a-kubernetes-cluster
+[Install and/or configure a Kubernetes cluster]: ../user/quick-start.md#install-andor-configure-a-kubernetes-cluster
 [kind-docker-hub]: https://hub.docker.com/r/kindest/node/tags
 [issue 3795]: https://github.com/kubernetes-sigs/cluster-api/issues/3795

docs/book/src/clusterctl/provider-contract.md

@@ -436,7 +436,7 @@ that are compliant with one of the following rules:
   * The object is directly or indirectly linked to a `ClusterResourceSet` object (through the `OwnerReference` chain).
   * The object is directly or indirectly linked to another object with the `clusterctl.cluster.x-k8s.io/move-hierarchy`
     label, e.g. the infrastructure Provider ClusterIdentity objects (linked through the `OwnerReference` chain).
-  * The object hase the `clusterctl.cluster.x-k8s.io/move` label or the `clusterctl.cluster.x-k8s.io/move-hierarchy` label,
+  * The object has the `clusterctl.cluster.x-k8s.io/move` label or the `clusterctl.cluster.x-k8s.io/move-hierarchy` label,
     e.g. the CPI config secret.
 
 Note. `clusterctl.cluster.x-k8s.io/move` and `clusterctl.cluster.x-k8s.io/move-hierarchy` labels could be applied

docs/book/src/developer/architecture/controllers/cluster-topology.md

@@ -12,7 +12,7 @@ Its main responsibilities are to:
 
 The high level workflow of ClusterTopology reconciliation is shown below.
 
-![ClusterTopology Reconciller Component Diagram](../../../images/cluster-topology-reconciller.png)
+![ClusterTopology Reconciler Component Diagram](../../../images/cluster-topology-reconciller.png)
 
 ### Additional information
 

docs/book/src/developer/architecture/controllers/control-plane.md

@@ -180,7 +180,7 @@ following fields defined:
       introspection by clients, and is used to provide the CRD-based integration
       for the scale subresource and additional integrations for things like
       kubectl describe. The string will be in the same format as the query-param
-      syntax. More info about label selectors: http://kubernetes.io/docs/user-guide/labels#label-selectors
+      syntax. More info about label selectors: https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/#label-selectors
     </td>
     <td></td>
   </tr>

docs/book/src/developer/architecture/controllers/machine-pool.md

@@ -10,7 +10,7 @@ The MachinePool controller's main responsibilities are:
     * The associated InfrastructureMachinePool object.
 * Copy data from `BootstrapConfig.Status.DataSecretName` to `MachinePool.Spec.Template.Spec.Bootstrap.DataSecretName` if
 `MachinePool.Spec.Template.Spec.Bootstrap.DataSecretName` is empty.
-* Setting NodeRefs on MachinePool instances to be able to associate them with kubernetes nodes.
+* Setting NodeRefs on MachinePool instances to be able to associate them with Kubernetes nodes.
 * Deleting Nodes in the target cluster when the associated MachinePool instance is deleted.
 * Keeping the MachinePool's Status object up to date with the InfrastructureMachinePool's Status object.
 * Finding Kubernetes nodes matching the expected providerIDs in the workload cluster.

docs/book/src/developer/architecture/controllers/machine.md

@@ -10,7 +10,7 @@ The Machine controller's main responsibilities are:
     * The associated InfrastructureMachine object.
 * Copy data from `BootstrapConfig.Status.DataSecretName` to `Machine.Spec.Bootstrap.DataSecretName` if
 `Machine.Spec.Bootstrap.DataSecretName` is empty.
-* Setting NodeRefs to be able to associate machines and kubernetes nodes.
+* Setting NodeRefs to be able to associate machines and Kubernetes nodes.
 * Deleting Nodes in the target cluster when the associated machine is deleted.
 * Cleanup of related objects.
 * Keeping the Machine's Status object up to date with the InfrastructureMachine's Status object.

docs/book/src/developer/e2e.md

@@ -18,9 +18,9 @@ test specs for the most common Cluster API use cases.
 
 Each E2E test requires a set of artifacts to be available:
 
-- Binaries & docker images for Kubernetes, CNI, CRI & CSI
-- Manifests & docker images for the Cluster API core components
-- Manifests & docker images for the Cluster API infrastructure provider; in most cases
+- Binaries & Docker images for Kubernetes, CNI, CRI & CSI
+- Manifests & Docker images for the Cluster API core components
+- Manifests & Docker images for the Cluster API infrastructure provider; in most cases
   machine images are also required (AMI, OVA etc.)
 - Credentials for the target infrastructure provider
 - Other support tools (e.g. kustomize, gsutil etc.)

docs/book/src/developer/logging.md

@@ -137,7 +137,7 @@ We are working to continuously improving this experience, allowing Cluster API d
 For the best experience exploring the logs using Tilt:
 1. Set `--logging-format=json`. 
 2. Set a high log verbosity, e.g. `v=5`.
-3. Enable promtail, loki, and grafana under deploy_observability.
+3. Enable Promtail, Loki, and Grafana under `deploy_observability`.
 
 A minimal example of a tilt-settings.yaml file that deploys a ready-to-use logging suite looks like:
 ```yaml

docs/book/src/developer/providers/contracts.md

@@ -5,7 +5,7 @@ Cluster API defines a contract which requires providers to implement certain fie
 Cluster API defines the following contracts:
 
 - [Infrastructure provider contract](./cluster-infrastructure.md)
-- [Boostrap provider contract](./bootstrap.md)
+- [Bootstrap provider contract](./bootstrap.md)
 - [Control Plane provider contract](../../developer/architecture/controllers/control-plane.md#crd-contracts)
 - [Machine provider contract](./machine-infrastructure.md)
 - [clusterctl provider contract](../../clusterctl/provider-contract.md#clusterctl-provider-contract)
@@ -14,7 +14,7 @@ Cluster API defines the following contracts:
 ## API version labels
 Providers MUST set `cluster.x-k8s.io/<version>` label on all Custom Resource Definitions related to Cluster API starting with v1alpha3.
 The label is a map from an API Version of Cluster API (contract) to your Custom Resource Definition versions.
-The value is a underscore-delimited (_) list of versions.
+The value is an underscore-delimited (_) list of versions.
 Each value MUST point to an available version in your CRD Spec.
 
 The label allows Cluster API controllers to perform automatic conversions for object references, the controllers will pick the last available version in the list if multiple versions are found.
@@ -33,4 +33,4 @@ An example of this is in the [Kubeadm Bootstrap provider](https://github.com/kub
 
 ## Improving and contributing to the contract
 
-The definition of the contract between Cluster API and providers may be changed in future versions of Cluster API. The Cluster API maintainers welcome feedback and contributions to the contract in order to improve how it's defined, its clarity and visibility to provider implementers and its suitability across the different kinds of Cluster API providers. To provide feedback or open a discussion about the provider contract please [open an issue on the Cluster API](https://github.com/kubernetes-sigs/cluster-api/issues/new?assignees=&labels=&template=feature_request.md) repo or add an item to the agenda in the [Cluster API community meeting](http://git.k8s.io/community/sig-cluster-lifecycle/README.md#cluster-api).
+The definition of the contract between Cluster API and providers may be changed in future versions of Cluster API. The Cluster API maintainers welcome feedback and contributions to the contract in order to improve how it's defined, its clarity and visibility to provider implementers and its suitability across the different kinds of Cluster API providers. To provide feedback or open a discussion about the provider contract please [open an issue on the Cluster API](https://github.com/kubernetes-sigs/cluster-api/issues/new?assignees=&labels=&template=feature_request.md) repo or add an item to the agenda in the [Cluster API community meeting](https://git.k8s.io/community/sig-cluster-lifecycle/README.md#cluster-api).

docs/book/src/developer/providers/v0.3-to-v0.4.md

@@ -22,7 +22,7 @@
 
 - The `test` folder now ships with its own Go module `sigs.k8s.io/cluster-api/test`.
 - The module is going to be tagged and versioned as part of the release.
-- Folks importing the test e2e framework or the docker infrastructure provider need to import the new module.
+- Folks importing the test e2e framework or the Docker infrastructure provider need to import the new module.
   - When imported, the test module version should always match the Cluster API one.
   - Add the following line in `go.mod` to replace the cluster-api dependency in the test module (change the version to your current Cluster API version):
   ```
@@ -199,7 +199,7 @@ should be executed before this changes.
 
 **Changes in the `/config/default` folder:**
 
-1. Edit the `/config/default/kustomization.yaml` file and replace all the occurencies of
+1. Edit the `/config/default/kustomization.yaml` file and replace all the occurrences of
    ```
          kind: Certificate
          group: cert-manager.io

docs/book/src/developer/providers/v1.0-to-v1.1.md

@@ -65,5 +65,5 @@ are kept in sync with the versions used by `sigs.k8s.io/controller-runtime`.
   fully exploit this feature, it is required to pass the `LogFolder` parameter when calling `CreateKindBootstrapClusterAndLoadImages`. Please see this [PR](https://github.com/kubernetes-sigs/cluster-api/pull/5910) for an example on how to use it. 
 * The `gci` linter has been enabled to enforce consistent imports. As usual, feel free to take a look at our linter config, but of course it's not mandatory to adopt it.
 * The Tilt dev setup has been extended with:
-    * [an option to deploy Grafana, Loki and promtail](https://github.com/kubernetes-sigs/cluster-api/pull/5336) 
+    * [an option to deploy Grafana, Loki and Promtail](https://github.com/kubernetes-sigs/cluster-api/pull/5336) 
     * [options to ease debugging of controllers (delve, profiler, metrics)](https://github.com/kubernetes-sigs/cluster-api/pull/5485) 

docs/book/src/developer/providers/v1.2-to-v1.3.md

@@ -62,14 +62,14 @@ The default value is 0, meaning that the volume can be detached without any time
 - The `Move` function in E2E test framework for clusterctl has been modified to:
   * print the `clusterctl move` command including the arguments similar to `Init`.
   * log the output to the a `clusterctl-move.log` file at the subdirectory `logs/<namespace>`.
-- The self-hosted upgrade test now also upgrades the self-hosted clusters kubernetes version by default. For that it requires the following variables to be set:
+- The self-hosted upgrade test now also upgrades the self-hosted cluster's Kubernetes version by default. For that it requires the following variables to be set:
   * `KUBERNETES_VERSION_UPGRADE_FROM`
   * `KUBERNETES_VERSION_UPGRADE_TO`
   * `ETCD_VERSION_UPGRADE_TO`
   * `COREDNS_VERSION_UPGRADE_TO`
-  The variable `SkipUpgrade` could be set to revert to the old behaviour by making use of the `KUBERNETES_VERSION` variable and skipping the kubernetes upgrade.
+  The variable `SkipUpgrade` could be set to revert to the old behaviour by making use of the `KUBERNETES_VERSION` variable and skipping the Kubernetes upgrade.
 - cert-manager upgraded from v1.9.1 to v1.10.1.
-- Machine `providerID` is now being strictly checked for equality when compared against Kubernetes node `providerID` data. This is the expected criteria for correlating a Cluster API machine to its corresponding Kubernetes node, but historically this comparison was not strict, and instead compared only against the `ID` substring part of the full `providerID` string. Because different providers construct `providerID` strings differently, the `ID` substring is not uniformly defined and implemented across providers, and thus the existing `providerID` equality can not guarantee the correct Machine-Node correlation. It is very unlikely that this new behavior will break existing providers, but FYI: if strict `providerID` equality will degrade expected behaviors, you may need to update your provider implementation prior to adopting Cluster API v1.3.
+- Machine `providerID` is now being strictly checked for equality when compared against Kubernetes node `providerID` data. This is the expected criteria for correlating a Cluster API machine to its corresponding Kubernetes node, but historically this comparison was not strict, and instead compared only against the `ID` substring part of the full `providerID` string. Because different providers construct `providerID` strings differently, the `ID` substring is not uniformly defined and implemented across providers, and thus the existing `providerID` equality cannot guarantee the correct Machine-Node correlation. It is very unlikely that this new behavior will break existing providers, but FYI: if strict `providerID` equality will degrade expected behaviors, you may need to update your provider implementation prior to adopting Cluster API v1.3.
 - The default minimum TLS version in use by the webhook servers is 1.2.
 - OwnerReferences are now more strictly enforced for objects managed by Cluster API. Machines, Bootstrap configs, Infrastructure Machines and Secrets created by CAPI components [now have strictly enforced controller owner references](https://github.com/kubernetes-sigs/cluster-api/issues/7575). This is not expected to require changes for providers.
 

docs/book/src/developer/repository-layout.md

@@ -29,7 +29,7 @@ cluster-api
 └───Makefile
 ```
 
-### Github
+### GitHub
 
 [~/.github](https://github.com/kubernetes-sigs/cluster-api/tree/main/.github)
 
@@ -57,7 +57,7 @@ This folder contains a reference implementation of a Cluster API Control Plane p
 
 ### Cluster API Provider Docker 
 
-[~/test/insfrastructure/docker](https://github.com/kubernetes-sigs/cluster-api/tree/main/test/infrastructure/docker)
+[~/test/infrastructure/docker](https://github.com/kubernetes-sigs/cluster-api/tree/main/test/infrastructure/docker)
 
 This folder contains a reference implementation of an infrastructure provider for the Cluster API project using Docker. This provider is intended for development purposes only. 
 
@@ -148,7 +148,7 @@ The [api](#api) folder contains webhooks consisting of validators and defaults f
 
 [~/internal/webhooks](https://github.com/kubernetes-sigs/cluster-api/tree/main/internal/webhooks)
 
-This directory contains the implementation of some of the Cluster API webhooks. The internal implementation means that the methods supplied by this package can not be imported by external code bases. 
+This directory contains the implementation of some of the Cluster API webhooks. The internal implementation means that the methods supplied by this package cannot be imported by external code bases. 
 
 [~/webhooks](https://github.com/kubernetes-sigs/cluster-api/tree/main/webhooks)
 

docs/book/src/developer/testing.md

@@ -193,11 +193,11 @@ kind images). This can be done by executing the `./scripts/ci-e2e.sh` script.
 GINKGO_FOCUS="\[PR-Blocking\]" ./scripts/ci-e2e.sh
 ```
 
-Now, the tests can be run in an IDE. The following describes how this can be done in Intellij IDEA and VS Code. It should work
+Now, the tests can be run in an IDE. The following describes how this can be done in IntelliJ IDEA and VS Code. It should work
 roughly the same way in all other IDEs. We assume the `cluster-api` repository has been checked
 out into `/home/user/code/src/sigs.k8s.io/cluster-api`.
 
-#### Intellij
+#### IntelliJ
 
 Create a new run configuration and fill in:
 * Test framework: `gotest`
@@ -555,8 +555,8 @@ In Cluster API Unit and integration test MUST use [go test].
 [Cluster API quick start]: ../user/quick-start.md
 [Cluster API test framework]: https://pkg.go.dev/sigs.k8s.io/cluster-api/test/framework?tab=doc
 [e2e development]: ./e2e.md
-[Ginkgo]: http://onsi.github.io/ginkgo/
-[Gomega]: http://onsi.github.io/gomega/
+[Ginkgo]: https://onsi.github.io/ginkgo/
+[Gomega]: https://onsi.github.io/gomega/
 [go test]: https://golang.org/pkg/testing/
 [controller-runtime]: https://github.com/kubernetes-sigs/controller-runtime
 [envtest]: https://github.com/kubernetes-sigs/controller-runtime/tree/master/pkg/envtest