v0.4.0

Quick Start

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/v0.4.0/manifests/install.yaml

Important Notes Before Upgrading

• For the BlueGreen strategy, Argo Rollouts will only pause rollouts that have the field spec.strategy.blueGreen.autoPromotionEnabled set to false. The default value of autoPromotionEnabled is true and causes the rollout to immediately promote the new version once it is available. This change was implemented to make the pausing behavior of rollouts more straight-forward and you can read more about it at #80. Argo Rollouts v0.3.2 introduces the autoPromotionEnabled flag without making any behavior changes, and those behavior changes are enforced starting at v0.4.0. In order to upgrade without any issues, the operator should first upgrade to v0.3.2 and add the autoPromotionEnabled flag with the appropriate value. Afterward, they will be safe to upgrade to v0.4.

• For the Canary Strategy, the Argo Rollouts controller stores a hash of the canary steps in the rollout status to be able to detect changes in steps. If the canary steps change during a progressing canary update, the controller will change the hash and restart the steps. If the rollout is in a completed state, the controller will only update the hash. In v0.4.0, the controller changed how the hash of the steps was calculated, and you can read more about that at this issues: #103. As a result, the operator should only upgrade Argo Rollouts to v0.4.0 when all the canary rollouts have executed all steps and have completed. Otherwise, the controller will restart the steps it has executed.

Changes since v0.3.2

Enhancements

• Add Ability to specify canaryService Service object to reach only canary pods #91
• Simplify unintuitive automatic pause behavior for blue green strategy #80
• Add back service informer to handle Service recreations quicker #71
• Use lister instead of kubernetes api call to load service #98
• Switch to controller-gen to generate crd with complete openapi validation spec #84

Bug Fixes

• Change step hashing function to derive hash from json representation #103
• CRD validation needs to be removed for resource requests/limits #101
• Possible to exceed revisionHistoryLimit with canary strategy #93
• Change in pod template hash after upgrading k8s dependencies #88
• Controller is missing patch event privileges bug #86
• Rollouts unprotected from invalid specs #84
• Fix logging fields #97

v0.3.2

Quick Start

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/v0.3.2/manifests/install.yaml

Important BlueGreen Strategy Change

In v0.4.0, Argo Rollouts will have a breaking change where we will only pause BlueGreen rollouts if they have a new field called autoPromotionEnabled under the spec.strategy.blueGreen set to false. If the field is not listed, the default value will be true, and the rollout will immediately promote the new Rollout. This change was introduced to address #80.

To prepare for v0.4.0, v0.3.2 will introduce the autoPromotionEnabled field, but the controller will not act on the field. As a result, you can add the autoPromotionEnabled field without breaking your existing rollouts.

Enhancements

• Add autoPromotionEnabled with no behavior change

Fixes

• Fix controller crash caused by glog attempting to write to /tmp (#94)

v0.3.1

Quick Start

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/v0.3.1/manifests/install.yaml

Breaking Changes

Rename autoPromoteActiveServiceDelaySeconds to autoPromotionSeconds #77

Changes since v0.3.0

Enhancements

• Switch to Scratch final image #67

Fixes

• Enable fast Rollback in BlueGreen #78
• Respect ScaleDownDelay during non-happy path #79
• Scale down older RS on non-happy path #76
• Fix issue where pod template hash could be computed inconsistently #75
• Cleanup replicasets in canary deployment #73
• Don't requeue 404 errors #72

v0.3.0

Quick Start

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/v0.3.0/manifests/install.yaml

New Features

• HPA Support #37
• Prometheus Metrics #29 #47
• Introduce ProgressDeadlineSeconds #54
• Improved Scalability #45

Breaking Changes

The status.verifyingPreview field was depreciated and move to spec.pause.

BlueGreen Specific

• Add previewReplicaCount #64
• Add ability to auto-promote active service #59
• Add ScaleDownDelaySeconds #57

Changes since v0.2.2

Enchantments

• HPA Support #37
• Prometheus Metrics #29
• Add previewReplicaCount #64
• Add ProgressDeadlineSeconds #54
• Add Invalid spec checks with regards to ProgressDeadlineSeconds #62
• Improve eventing and metrics #61
• Improve Available Condition #60
• Convert Kustomize V1.0 to Kustomize v2.0 #56
• Make Metrics port customizable #55
• Replace gometalinter with golangci #46
• Add support for gotestsum #52
• Remove service informer #45
• Replace verifying preview with Paused #43

Bug fixes

• Prevent early pause before svc change in BG #51
• Fix aggregate roles naming collision with Argo Workflows #44
• Use recreate strategy for controller #44

v0.2.2

Add missing events permissions to the clusterrole

v0.2.1

Changes the following clusterroles to prevent name collision with Argo Workflows

• argo-aggregate-to-admin to argo-rollouts-aggregate-to-admin
• argo-aggregate-to-edit to argo-rollouts-aggregate-to-edit
• argo-aggregate-to-view to argo-rollouts-aggregate-to-view

v0.2.0

• Implements the initial ReplicaSet-based Canary Strategy
• Cleans up Status fields
• Implicit understanding of rollback based on steps completion and pod hash for Blue Green and Canary

v0.1.0

• Creates a controller that manages a rollout object that mimics a deployment object
• Declaratively offers a Blue Green Strategy by creating the replicaset from the spec and managing an active and preview service to point to the new replicaset