Quick Start

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.

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