Ensure Argo Rollout specify scaleDownDelayRevisionLimit to reduce cost

[noaabarki]

Describe the solution you'd like

We want to add a new default rule for the Argo policy that will verify blue-green Rollouts are configured scaleDownDelaySeconds with value 2. For instance the following manifest configured scaleDownDelayRevisionLimit with a value of 2.

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: example-bluegreen
spec:
   strategy:
      blueGreen:
        scaleDownDelayRevisionLimit: 2

Requirements

• The rule should be OFF be default.
• The rule identifier should be ARGO_ROLLOUT_MISSING_SCALE_DOWN_DELAY_REVISION_LIMIT.

How to create new default rule?

1. Write the rule logic in JSON schema (but in yaml format). For you convenience you can use our online yaml schema validator tool.
2. Add the new rule as default rule:
   1. Add new entry in the pkg/defaultRules/defaultRules.yaml.
   2. Increase the minItems++, maxItems++, maximum++ properties of rules in pkg/defaultRules/defaultRulesSchema.json
3. Hooray! Submit a PR 🙂

Guidelines

• The implementation require Golang beginner level and JSON schema familarity.
• All default rules are written in JSON schema and located in defaultRules package.
• The validation itself is happening in the JsonSchemaValidator package function ValidateYamlSchema.The validation process happens in bl/evaluation/evaluator.go -> *evaluateRule(..)*for every configuration that exists in every file that exists in a given path.
• Checkout rules CONTAINERS_MISSING_CPU_REQUEST_KEY and ARGO_WORKFLOW_INCORRECT_REVISION_HISTORY_LIMIT_VALUE_0 as references.

📖 The reason behind the rule

Imagine the following scenario: you performing blue-green updates. You probably want to leave the old stacks running (e.g. 24 hours) in case you want to rollback. After that, it is okay to scale down. For this, you would specify scaleDownDelaySeconds: 86400.

However, if you perform 10 updates, you don't want to leave 10 full stacks running, each of them for 24 hours. You would only like to keep the last 2 stacks up and running. For this, you would specify scaleDownDelayRevisionLimit: 2

resource