docs: fix missing fields in canary spec (argoproj#1236)

- ScaleDownDelaySeconds and ScaleDownDelayRevisionLimit
  for canary

Signed-off-by: Hui Kang <[email protected]>

Author: huikang

docs/FAQ.md

@@ -46,7 +46,7 @@ Argo Rollouts supports BlueGreen, Canary, and Rolling Update. Additionally, Prog
 As with Deployments, Rollouts does not follow the strategy parameters on the initial deploy. The controller tries to get the Rollout into a steady state as fast as possible. The controller tries to get the Rollout into a steady state as fast as possible by creating a fully scaled up ReplicaSet from the provided `.spec.template`. Once the Rollout has a stable ReplicaSet to transition from, the controller starts using the provided strategy to transition the previous ReplicaSet to the desired ReplicaSet.
 
 ### How does BlueGreen rollback work?
-A BlueGreen Rollout keeps the old ReplicaSet up and running for 30 seconds or the value of the scaleDownDelaySeconds. The controller tracks the remaining time before scaling down by adding an annotation called `argo-rollouts.argoproj.io/scale-down-deadline` to the old ReplicaSet. If the user applies the old Rollout manifest before the old ReplicaSet before it scales down, the controller does something called a fast rollback. The controller immediately switches the active service’s selector back to the old ReplicaSet’s rollout-pod-template-hash and removes the scaled down annotation from that ReplicaSet. The controller does not do any of the normal operations when trying to introduce a new version since it is trying to revert as fast as possible. A non-fast-track rollback occurs when the scale down annotation has past and the old ReplicaSet has been scaled down. In this case, the Rollout treats the ReplicaSet like any other new ReplicaSet and follows the usual procedure for deploying a new ReplicaSet.
+A BlueGreen Rollout keeps the old ReplicaSet up and running for 30 seconds or the value of the scaleDownDelaySeconds. The controller tracks the remaining time before scaling down by adding an annotation called `argo-rollouts.argoproj.io/scale-down-deadline` to the old ReplicaSet. If the user applies the old Rollout manifest before the old ReplicaSet scales down, the controller does something called a fast rollback. The controller immediately switches the active service’s selector back to the old ReplicaSet’s rollout-pod-template-hash and removes the scaled down annotation from that ReplicaSet. The controller does not do any of the normal operations when trying to introduce a new version since it is trying to revert as fast as possible. A non-fast-track rollback occurs when the scale down annotation has past and the old ReplicaSet has been scaled down. In this case, the Rollout treats the ReplicaSet like any other new ReplicaSet and follows the usual procedure for deploying a new ReplicaSet.
 
 ### What is the `argo-rollouts.argoproj.io/managed-by-rollouts` annotation?
 Argo Rollouts adds an `argo-rollouts.argoproj.io/managed-by-rollouts` annotation to Services and Ingresses that the controller modifies. They are used when the Rollout managing these resources is deleted and the controller tries to revert them back into their previous state.

docs/features/specification.md

@@ -173,6 +173,19 @@ spec:
       # original pods. +optional
       maxSurge: "20%"
 
+      # Adds a delay before scaling down the previous ReplicaSet when the
+      # canary strategy is used with traffic routing (default 30 seconds).
+      # A delay in scaling down the previous ReplicaSet is needed after
+      # switching the stable service selector to point to the new ReplicaSet,
+      # in order to give time for traffic providers to re-target the new pods.
+      # This value is ignored with basic, replica-weighted canary without
+      # traffic routing.
+      ScaleDownDelaySeconds: 30
+
+      # Limits the number of old RS that can run at one time before getting
+      # scaled down. Defaults to nil
+      ScaleDownDelayRevisionLimit: 2
+
       # Background analysis to run during a rollout update. Skipped upon
       # initial deploy of a rollout. +optional
       analysis: