docs: minor formatting corrections. Fixes #1113

Signed-off-by: Kostis Kapelonis <[email protected]>

docs/CONTRIBUTING.md

@@ -12,6 +12,7 @@ Install:
 * [minikube](https://kubernetes.io/docs/setup/minikube/) or Docker for Desktop
 
 Argo Rollout additionally uses the following tools
+
 * `golangci-lint` to lint the project.
 * `protoc` and `swagger-codegen` to generate proto related files
 * `yarn` to build the UI

docs/FAQ.md

@@ -24,6 +24,7 @@ This command executes the action listed on the application listed.
 In the UI, a user can click the hamburger button of a resource and the available actions will appear in a couple of seconds. The user can click and confirm that action to execute it.
 
 Currently, the Rollout action has two available custom actions in Argo CD: resume and restart.
+
 * Resume unpauses a Rollout with a PauseCondition
 * Restart: Sets the RestartAt and causes all the pods to be restarted.
 

docs/features/canary.md

@@ -2,12 +2,12 @@
 A canary rollout is a deployment strategy where the operator releases a new version of their application to a small percentage of the production traffic. 
 
 ## Overview
-Since there is no agreed upon standard for a canary deployment, the rollouts controller allows users to outline how they want to run their canary deployment. Users can define a list of steps the controller uses to manipulate the ReplicaSets where there is a change to the `.spec.template`. Each step will be evaluated before the new ReplicaSet is promoted to the stable version, and the old version is completely scaled down.
+Since there is no agreed upon standard for a canary deployment, the rollouts controller allows users to outline how they want to run their canary deployment. Users can define a list of steps the controller uses to manipulate the ReplicaSets when there is a change to the `.spec.template`. Each step will be evaluated before the new ReplicaSet is promoted to the stable version, and the old version is completely scaled down.
 
 Each step can have one of two fields. The `setWeight` field dictates the percentage of traffic that should be sent to the canary, and the `pause` struct instructs the rollout to pause.  When the controller reaches a `pause` step for a rollout, it will set adds a PauseCondition struct to the `.status.PauseConditions` field. If the `duration` field within the `pause` struct is set, the rollout will not progress to the next step until it has waited for the value of the `duration` field. Otherwise, the rollout will wait indefinitely until that Pause condition is removed. By using the `setWeight` and the `pause` fields, a user can declarative describe how they want to progress to the new version. Below is an example of a canary strategy.
 
 !!! important
-    If the canary Rollout does not use [traffic management](traffic-management/index.md), the Rollout makes a best effort attempt to achieve the percentage listed in the last `setWeight` step between the new and old version. For example, if a Rollout has 10 Replicas and 10% for the first `setWeight` step, the controller will scale the new desired ReplicaSet to 1 replicas and the old stable ReplicaSet to 9. In the case where the setWeight is 15%, the Rollout attempts to get there by rounding up the calculation (i.e. the new ReplicaSet has 2 pod since 15% * 10 rounds up to 2 and the old ReplicaSet has 9 pod since 85% * 10 rounds up to 9). If a user wants to have more fine-grained control of the percentages without a large number of Replicas, that user should use the  [traffic management](#trafficrouting) functionality.
+    If the canary Rollout does not use [traffic management](traffic-management/index.md), the Rollout makes a best effort attempt to achieve the percentage listed in the last `setWeight` step between the new and old version. For example, if a Rollout has 10 Replicas and 10% for the first `setWeight` step, the controller will scale the new desired ReplicaSet to 1 replicas and the old stable ReplicaSet to 9. In the case where the setWeight is 15%, the Rollout attempts to get there by rounding up the calculation (i.e. the new ReplicaSet has 2 pods since 15% of 10, rounds up to 2 and the old ReplicaSet has 9 pods since 85% of 10, rounds up to 9). If a user wants to have more fine-grained control of the percentages without a large number of Replicas, that user should use the  [traffic management](#trafficrouting) functionality.
 
 ## Example
 ```yaml
@@ -59,7 +59,7 @@ spec:
         - pause: {}                # pause indefinitely
 ```
 
-If no `duration` specified for a pause step the rollout will be paused indefinitely. To unpause use the [argo kubectl plugin](kubectl-plugin.md) `promote` command. 
+If no `duration` is specified for a pause step, the rollout will be paused indefinitely. To unpause, use the [argo kubectl plugin](kubectl-plugin.md) `promote` command. 
 
 ```shell
 # promote to the next step
@@ -69,17 +69,17 @@ kubectl argo rollouts promote <rollout>
 ## Controlling Canary Scale
 
 By default, the rollout controller will scale the canary to match the current trafficWeight of the
-current step. For example, if the current weight is 25%, and there are four replicas, there the
+current step. For example, if the current weight is 25%, and there are four replicas, then the
 canary will be scaled to 1, to match the traffic weight.
 
 It is possible to control the canary replica's scale during the steps such that it does not necessary
 match the traffic weight. Some use cases for this:
 
 1. The new version should not yet be exposed to the public (setWeight: 0), but you would like to
-   scale the canary up in order for testing purposes.
+   scale the canary up for testing purposes.
 2. You wish to scale the canary stack up minimally, and use some header based traffic shaping to
    the canary, while setWeight is still set to 0.
-3. You wish to scale the canary up 100%, in order to facilitate traffic shadowing.
+3. You wish to scale the canary up to 100%, in order to facilitate traffic shadowing.
 
 
 !!! important
@@ -88,8 +88,9 @@ match the traffic weight. Some use cases for this:
 
 To control canary weights during steps, use the `setCanaryScale` step and indicate which scale the
 the canary should use:
+
 * explicit replica count
-* explicit weight percentage of total spec.repicas
+* explicit weight percentage of total spec.replicas
 * to match current canary setWeight
 
 ```yaml
@@ -108,7 +109,7 @@ spec:
           matchTrafficWeight: true
 ```
 
-If no `duration` specified for a pause step the rollout will be paused indefinitely. To unpause use the [argo kubectl plugin](kubectl-plugin.md) `promote` command. 
+If no `duration` is specified for a pause step, the rollout will be paused indefinitely. To unpause, use the [argo kubectl plugin](kubectl-plugin.md) `promote` command. 
 
 ```shell
 # promote to the next step
@@ -117,7 +118,7 @@ kubectl argo rollouts promote <rollout>
 
 
 ## Mimicking Rolling Update
-If the steps field is omitted, the canary strategy will mimic the rolling update behavior. Similar to the deployment, the canary strategy has the `maxSurge` and `maxUnavailable` fields to configure how the Rollout should progress to the new version.
+If the `steps` field is omitted, the canary strategy will mimic the rolling update behavior. Similar to the deployment, the canary strategy has the `maxSurge` and `maxUnavailable` fields to configure how the Rollout should progress to the new version.
 
 ## Other Configurable Features
 Here are the optional fields that will modify the behavior of canary strategy:
@@ -151,7 +152,7 @@ Defaults to nil
 Defaults to an empty string
 
 ### stableService
-`stableService` the name of a Service which selects pods with stable version and don't select any pods with canary version. This allows users to only hit the stable ReplicaSet.
+`stableService` the name of a Service which selects pods with stable version and doesn't select any pods with canary version. This allows users to only hit the stable ReplicaSet.
 
 Defaults to an empty string
 

docs/features/traffic-management/alb.md

@@ -188,10 +188,11 @@ spec:
       containers:
       - name: argo-rollouts
         args: [--alb-verify-weight]
- ```
+```
 
 For this feature to work, the argo-rollouts deployment requires the following AWS API permissions
 under the [Elastic Load Balancing API](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/Welcome.html):
+
 * `DescribeTargetGroups`
 * `DescribeLoadBalancers`
 * `DescribeListeners`
@@ -201,6 +202,7 @@ under the [Elastic Load Balancing API](https://docs.aws.amazon.com/elasticloadba
 There are various ways of granting AWS privileges to the argo-rollouts pods, which is highly
 dependent to your cluster's AWS environment, and out-of-scope of this documentation. Some solutions
 include:
+
 * AWS access and secret keys
 * [kiam](https://github.com/uswitch/kiam)
 * [kube2iam](https://github.com/jtblin/kube2iam)

docs/features/traffic-management/istio.md

@@ -120,6 +120,7 @@ spec:
 ```
 
 During the lifecycle of a Rollout update, Argo Rollouts will continuously:
+
 * modify the canary Service `spec.selector` to contain the `rollouts-pod-template-hash` label of the canary ReplicaSet
 * modify the stable Service `spec.selector` to contain the `rollouts-pod-template-hash` label of the stable ReplicaSet
 * modify the VirtualService `spec.http[].route[].weight` to match the current desired canary weight
@@ -239,6 +240,7 @@ spec:
 ```
 
 During the lifecycle of a Rollout using Istio DestinationRule, Argo Rollouts will continuously:
+
 * modify the VirtualService `spec.http[].route[].weight` to match the current desired canary weight
 * modify the DestinationRule `spec.subsets[].labels` to contain the `rollouts-pod-template-hash`
   label of the canary and stable ReplicaSets