Fix typo in docs/proposals

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

Author: chymy

docs/proposals/20181121-machine-api.md

@@ -42,9 +42,9 @@ performed in-place or via Node replacement.
 ## Proposal
 
 This proposal introduces a new API type: Machine. See the full definition in
-[types.go](types.go).
+[machine_types.go](../../api/v1alpha4/machine_types.go).
 
-A "Machine" is the declarative spec for a Node, as represented in Kuberenetes
+A "Machine" is the declarative spec for a Node, as represented in Kubernetes
 core. If a new Machine object is created, a provider-specific controller will
 handle provisioning and installing a new host to register as a new Node matching
 the Machine spec. If the Machine's spec is updated, a provider-specific
@@ -143,4 +143,4 @@ revisit the specifics when new patterns start to emerge in core.
 
 ## Types
 
-Please see the full types [here](https://github.com/kubernetes-sigs/cluster-api/tree/release-0.2/pkg/apis/deprecated/v1alpha1/machine_types.go).
+Please see the full types [here](../../api/v1alpha4/machine_types.go).

docs/proposals/20191016-clusterctl-redesign.md

@@ -2,8 +2,8 @@
 title: Clusterctl redesign - Improve user experience and management across Cluster API providers
 authors:
   - "@timothysc"
-  - “@frapposelli”
-  - “@fabriziopandini” 
+  - "@frapposelli"
+  - "@fabriziopandini" 
 reviewers:
   - "@detiber"
   - "@ncdc"

docs/proposals/20191017-kubeadm-based-control-plane.md

@@ -131,10 +131,10 @@ Non-Goals listed in this document are intended to scope bound the current v1alph
 - To mutate the configuration of live, running clusters (e.g. changing api-server flags), as this is the responsibility of the [component configuration working group](https://git.k8s.io/community/wg-component-standard).
 - To provide configuration of external cloud providers (i.e. the [cloud-controller-manager](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/)).This is deferred to kubeadm.
 - To provide CNI configuration. This is deferred to external, higher level tooling.
-- To provide the upgrade logic to handle changes to infrastructure (networks, firewalls etc…) that may need to be done to support a control plane on a newer version of Kubernetes (e.g. a cloud controller manager requires updated permissions against infrastructure APIs). We expect the work on [add-on components](https://git.k8s.io/community/sig-cluster-lifecycle#cluster-addons)) to help to resolve some of these issues.
+- To provide the upgrade logic to handle changes to infrastructure (networks, firewalls etc…) that may need to be done to support a control plane on a newer version of Kubernetes (e.g. a cloud controller manager requires updated permissions against infrastructure APIs). We expect the work on [add-on components](https://git.k8s.io/community/sig-cluster-lifecycle#cluster-addons) to help to resolve some of these issues.
 - To provide automation around the horizontal or vertical scaling of control plane components, especially as etcd places hard performance limits beyond 3 nodes (due to latency).
 - To support upgrades where the infrastructure does not rely on a Load Balancer for access to the API Server.
-- To implement a fully modeled state machine and/or Conditions, a larger effort for Cluster API more broadly is being organized on [this issue](https://github.com/kubernetes-sigs/cluster-api/issues/1658))
+- To implement a fully modeled state machine and/or Conditions, a larger effort for Cluster API more broadly is being organized on [this issue](https://github.com/kubernetes-sigs/cluster-api/issues/1658)
 
 ## Proposal
 

docs/proposals/20191030-machine-health-checking.md

@@ -90,7 +90,7 @@ MHC requests a remediation in one of the following ways:
 - Creating a CR based on a template which signals external component to remediate the machine 
 
 It provides a short-circuit mechanism and limits remediation when the number of unhealthy machines is not within `unhealthyRange`, or has reached `maxUnhealthy` threshold for a targeted group of machines with `unhealthyRange` taking precedence.
-This is similar to what the node life cycle controller does for reducing the eviction rate as nodes become unhealthy in a given zone. E.g a large number of nodes in a single zone are down due to a networking issue.
+This is similar to what the node life cycle controller does for reducing the eviction rate as nodes become unhealthy in a given zone. E.g. a large number of nodes in a single zone are down due to a networking issue.
 
 The machine health checker is an integration point between node problem detection tooling expressed as node conditions and remediation to achieve a node auto repairing feature.
 
@@ -104,7 +104,7 @@ If any of those criteria are met for longer than the given timeouts and the numb
 
 Timeouts:
 - For the node conditions the time outs are defined by the admin.
-- For a machine with no nodeRef an opinionated value could be assumed e.g 10 min.
+- For a machine with no nodeRef an opinionated value could be assumed e.g. 10 min.
 
 ### Remediation:
 - Remediation is not an integral part or responsibility of MachineHealthCheck. This controller only functions as a means for others to act when a Machine is unhealthy in the best way possible.
@@ -376,7 +376,7 @@ For failing early testing we could consider a test suite leveraging kubemark as
 [testing-guidelines]: https://git.k8s.io/community/contributors/devel/sig-testing/testing.md
 
 ### Graduation Criteria [optional]
-This propose the new CRD to belong to the same API group than other cluster-api resources, e.g machine, machineSet and to follow the same release cadence.
+This propose the new CRD to belong to the same API group than other cluster-api resources, e.g. machine, machineSet and to follow the same release cadence.
 
 ### Version Skew Strategy [optional]
 

docs/proposals/20200330-spot-instances.md

@@ -102,7 +102,7 @@ Allow users to cut costs of running Kubernetes clusters on cloud providers by mo
 
 - Any logic for choosing instances types based on availability from the cloud provider
 
-- A one to one map for each provider available mechanism for deploying spot instances, e.g aws fleet.
+- A one to one map for each provider available mechanism for deploying spot instances, e.g. aws fleet.
 
 - Support Spot instances via MachinePool for any cloud provider that doesn't already support MachinePool
 
@@ -315,7 +315,7 @@ could introduce instability to the cluster or even result in a loss of quorum fo
 Running control-plane instances on top of spot instances should be forbidden.
 
 There may also be limitations within cloud providers that restrict the usage of spot instances within the control-plane,
-eg. Azure Spot VMs do not support [ephemeral disks](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/spot-vms#limitations) which may be desired for control-plane instances.
+e.g. Azure Spot VMs do not support [ephemeral disks](https://docs.microsoft.com/en-us/azure/virtual-machines/linux/spot-vms#limitations) which may be desired for control-plane instances.
 
 This risk will be documented and it will be strongly advised that users do not attempt to create control-plane instances on spot instances.
 To prevent it completely, an admission controller could be used to verify that Infrastructure Machines do not get created with the control-plane label,
@@ -459,7 +459,7 @@ Spot VMs are available in two forms in Azure.
 ###### Scale Sets
 
 Scale sets include support for Spot VMs by indicating when created, that they should be backed by Spot VMs.
-At this point, a eviction policy should be set and a maximum price you wish to pay.
+At this point, an eviction policy should be set and a maximum price you wish to pay.
 Alternatively, you can also choose to only be preempted in the case that there are capacity constraints,
 in which case, you will pay whatever the market rate is, but will be preempted less often.
 
@@ -468,7 +468,7 @@ Once support is added, enabling Spot backed Scale Sets would be a case of modify
 
 ###### Single Instances
 Azure supports Spot VMs on single VM instances by indicating when created, that the VM should be a Spot VM.
-At this point, a eviction policy should be set and a maximum price you wish to pay.
+At this point, an eviction policy should be set and a maximum price you wish to pay.
 Alternatively, you can also choose to only be preempted in the case that there are capacity constraints,
 in which case, you will pay whatever the market rate is, but will be preempted less often.
 

docs/proposals/20200423-etcd-data-disk.md

@@ -5,7 +5,7 @@ authors:
 reviewers:
   - "@bagnaram"
   - "@vincepri"
-  - “@detiber”
+  - "@detiber"
   - "@fabrizio.pandini"
 creation-date: 2020-04-23
 last-updated: 2020-05-11
@@ -80,9 +80,9 @@ As a user of a Workload Cluster, I want provision and mount additional data stor
 
 ### Implementation Details/Notes/Constraints
 
-### Changes required in the bootstrap provider (ie. CABPK)
+### Changes required in the bootstrap provider (i.e. CABPK)
 
-1. Add a two new fields to KubeadmConfig for disk setup and mount points
+1. Add two new fields to KubeadmConfig for disk setup and mount points
 
 ```go
    // DiskSetup specifies options for the creation of partition tables and file systems on devices.

docs/proposals/20200506-conditions.md

@@ -254,7 +254,7 @@ ControlPlaneReady=False, Reason=ScalingUp, Severity=Info
 ```
 
 In other cases, the combination of `Reason` and `Severity` allows to detect when a failure is due to a catastrophic
-error or to other events that are transient or can be eventually remediated by an user intervention
+error or to other events that are transient or can be eventually remediated by a user intervention
 
 ```
 MachineReady=False, Reason=MachineNotHealthy, Severity=Error
@@ -456,7 +456,7 @@ time an upgrade starts.
 Then, those new conditions will be then captured by the summary in `KubeadmControlPlane.Status.Conditions[Ready]`
 and be reflected to `Cluster.Status.Conditions[ControlPlaneReady]`.
 
-However, please note that during upgrades, some rules that are be used to evaluate the
+However, please note that during upgrades, some rules that are been used to evaluate the
 operational state of a control plane should be temporary changed e.g. during upgrades:
 
 - It is acceptable to have a number of replicas higher than the desired number of replicas
@@ -482,11 +482,11 @@ enhance the condition utilities to handle those situations in a generalized way.
   - Mitigation: Ensure all the implementations comply with the defined set of constraints/design principles. 
 
 - Risk: Having a consistent polarity ensures a simple and clear contract with the consumers, and it allows 
-  processing conditions in a simple and consistent way without being forced to implements specific logic
+  processing conditions in a simple and consistent way without being forced to implement specific logic
   for each condition type. However, we are aware about the fact that enforcing of consistent polarity (truthy)
   combined with the usage of recommended suffix for condition types can lead to verbal contortions to express 
   conditions, especially in case of conditions designed to signal problems or in case of conditions
-  that might exists or not.
+  that might exist or not.
   - Mitigation: We are relaxing the rule about recommended suffix and allowing usage of custom suffix.
   - Mitigation: We are recommending the condition adhere to the design principle to express the operational state
     of the component, and this should help in avoiding conditions name to surface internal implementation details.

docs/proposals/20200511-clusterctl-extensible-template-processing.md

@@ -3,10 +3,10 @@ title: Extensible Templating Processing for clusterctl
 authors:
 * "@wfernandes"
 reviewers:
-* ”@timothysc”
-* “@ncdc”
-* “@fabriziopandini”
-* “@vincepri”
+* "@timothysc"
+* "@ncdc"
+* "@fabriziopandini"
+* "@vincepri"
 
 
 creation-date: 2020-04-27
@@ -233,12 +233,12 @@ libraries so the issue of support should be solved with this contract.
 - Currently, clusterctl relies on the conformance of file name conventions
   such as `infrastructure-components.yaml` and
   `cluster-template-<flavor>.yaml`. Other templating tools might require other
-  conventions to be defined and followed to allow the same “day 1” experience.
+  conventions to be defined and followed to allow the same "day 1" experience.
 - Some templating tools will require multiple files to be defined rather than
-  a single yaml file. These artifacts will need to be “grouped” together to
+  a single yaml file. These artifacts will need to be "grouped" together to
   support current retrieval mechanisms. Currently, `clusterctl config cluster`
   retrieves templates from multiple sources such as ConfigMaps within a
-  cluster, URL, Github Repository, Local Repository and even the overrides'
+  cluster, URL, Github Repository, Local Repository and even the overrides
   directory. To ensure compatibility, we’ll need to establish a compression
   format like tar.gz
 

docs/proposals/20200602-machine-deletion-phase-hooks.md

@@ -109,7 +109,7 @@ lifecycle hook.
 - Create a mechanism to signal what lifecycle point a machine is at currently.
 - Dictate implementation of controllers that respond to the hooks.
 - Implement ordering in the machine-controller.
-- Require anyone uses these hooks for normal machine operations, these are
+- Require anyone to use these hooks for normal machine operations, these are
 strictly optional and for custom integrations only.
 
 

docs/proposals/20210203-externally-managed-cluster-infrastructure.md

@@ -56,7 +56,7 @@ Refer to the [Cluster API Book Glossary](https://cluster-api.sigs.k8s.io/referen
 ### Managed cluster infrastructure
 
 Cluster infrastructure whose lifecycle is managed by a provider InfraCluster controller.
-E.g in AWS:
+E.g. in AWS:
 - Network
     - VPC
     - Subnets

docs/proposals/20210210-insulate-users-from-kubeadm-API-changes.md

@@ -63,7 +63,7 @@ should take this opportunity to stop relying on the assumption that the kubeadm
 KubeadmConfig/KubeadmControlPlane specs are supported(1) by all the Kubernetes/kubeadm version
 in the support range.
 
-This would allow to separate what users fill in in the KubeadmConfig/KubeadmControlPlane
+This would allow to separate what users fill in the KubeadmConfig/KubeadmControlPlane
 from which kubeadm API version Cluster API end up using in the bootstrap data.
 
 (1) Supported in this context means that the serialization format of the types is the same,