* chore: bumping k8s mods to 0.30.11 and new CRD
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* chore: updating more modules and tweaking CRD generation
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* chore: adding StormForge on USERS.md
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* tweaking Makefile and supporting script to successfully run codegen
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* removed deprecated generate-groups.sh codegen script
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* Updating gen-openapi parameters k8s to v0.30.X
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* running go mod before generating crd
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* another pass on fixing go-to-protobuf
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* restoring boilerplate.go.txt for gen_client
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* tweaking openapi-gen for the expected file name
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* disable vendoring on gen-crd
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* disable vendoring for docs generation
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* invoking doc generation prior crd generation
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* bumping mockery version
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* adding go-mod-vendor for docs
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* bumping to latest k8s libraries 0.30.X
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* bumping golang
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* bumping last k8s libraries and reinstate go 1.23
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* fixing codegen directory
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* resolving conflicts on x/sync
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* bumping k8s libraries to 1.30.14
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* another pass after go mod tidy
Signed-off-by: Rafael Brito <rafa@stormforge.io>
* Makefile changes to support go module style setup with new codegen
Signed-off-by: Rafael Brito <rafa@stormforge.io>
---------
Signed-off-by: Rafael Brito <rafa@stormforge.io>
Signed-off-by: Rafael Brito <rafaelbrito@gmail.com>
* Fix camelCase typo in metricsPort CLI flag
Signed-off-by: Kevin Park <krapi0314@gmail.com>
* Expose AWS API version in controller CLI
Signed-off-by: Kevin Park <krapi0314@gmail.com>
---------
Signed-off-by: Kevin Park <krapi0314@gmail.com>
* fix: remove preserveUnknownFields to avoid OutOfSync in ArgoCD
fixes https://github.com/argoproj/argo-rollouts/issues/1272
Signed-off-by: Johannes Kleinlercher <johannes.kleinlercher@suxess-it.com>
* chore: added suxess-it as users
Signed-off-by: Johannes Kleinlercher <johannes.kleinlercher@suxess-it.com>
* fix: remove preserveUnknownFields in gen-crd-spec
Signed-off-by: Johannes Kleinlercher <johannes.kleinlercher@suxess-it.com>
---------
Signed-off-by: Johannes Kleinlercher <johannes.kleinlercher@suxess-it.com>
* fix: fix abort scenario where canary/stable service is not provided
Signed-off-by: Peter Jiang <peterjiang823@gmail.com>
* remove not needed code
Signed-off-by: Peter Jiang <peterjiang823@gmail.com>
* Modularize tests
Signed-off-by: Peter Jiang <peterjiang823@gmail.com>
* fix tests
Signed-off-by: Peter Jiang <peterjiang823@gmail.com>
* Refactor code to handle only checking relavant RS and return nil
Signed-off-by: Peter Jiang <peterjiang823@gmail.com>
* update test
Signed-off-by: Peter Jiang <peterjiang823@gmail.com>
* update test
Signed-off-by: Peter Jiang <peterjiang823@gmail.com>
---------
Signed-off-by: Peter Jiang <peterjiang823@gmail.com>
* docs: blue green w/ ALB not supported
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* docs: blue green w/ ALB not supported
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* docs: blue green w/ ALB not supported
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* docs: blue green w/ ALB not supported
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* docs: blue green w/ ALB not supported
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* docs: blue green w/ ALB not supported
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* Update docs/features/bluegreen.md
Co-authored-by: Leonardo Luz Almeida <leoluz@users.noreply.github.com>
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* Update docs/features/bluegreen.md
Co-authored-by: Leonardo Luz Almeida <leoluz@users.noreply.github.com>
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* docs: blue green w/ ALB not supported
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
Co-authored-by: Leonardo Luz Almeida <leoluz@users.noreply.github.com>
docs: fix some typos and tweaks to istio documentation
Signed-off-by: Steve Ramage <gitcommits@sjrx.net>
Co-authored-by: Steve Ramage <gitcommits@sjrx.net>
* fix(trafficrouting): patch VirtualService when there is only one named route
Signed-off-by: Jean Morais <jeancdemorais@gmail.com>
* test(trafficrouting): fix TestGetHttpRouteIndexesToPatch
Signed-off-by: Jean Morais <jeancdemorais@gmail.com>
---------
Signed-off-by: Jean Morais <jeancdemorais@gmail.com>
* fix: loop when paused and completed
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix: loop when paused and completed
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix: loop when paused and completed
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* cleanup
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add e2e tests
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix: loop when paused and completed
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix: loop when paused and completed
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix: loop when paused and completed
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* cleanup
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add e2e tests
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add comments
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* use function for completed
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* remove un-used variable
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* chore: ignore all debug_bin*
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* feat(experiments): Add a utility to check if an experiment belongs to a Rollout. We can then identify when an experiment is a Step in a Rollout.
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* chore: typo
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* feat(experiments): Fire k8s Event bound to the Rollout when it owns the Experiment
Addresses #4009. This change will fire Analysis Run events bound to the parent Rollout object when the Experiment is a Step in the Rollout.
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* Loop through ownerReferences to find the rollout reference.
If we pass belongs to rollout check, we know there is a rollout to find.
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* Tighten things up - don't need a bool - fetch the ref or nil
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
---------
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* perf: reconcile pod ephemeral metadata in parallel
Signed-off-by: Jordan Rodgers <jrodgers@figma.com>
* update tests for multiple pods
Signed-off-by: Jordan Rodgers <jrodgers@figma.com>
---------
Signed-off-by: Jordan Rodgers <jrodgers@figma.com>
fix(experiments): propagate rolouts labels to experiments and replica sets
Enhancement ticket: https://github.com/argoproj/argo-rollouts/issues/4113
This can be useful for complying to Tagging Policy imposed at cluster level
since there is no mechanism to add custom labels to Experiments and their
associated ReplicaSets.
Indeed, this could enable automatic reporting but also give required information
for investigation.
Signed-off-by: Ahmed YUREIDINI NOGALES <ahmed.yureidini@gmail.com>
Co-authored-by: Ahmed YUREIDINI NOGALES <ayureidininogales@ncelrnd2709.nce.amadeus.net>
* fix: check ephemeral metadata is set before delete
Signed-off-by: Jordan Rodgers <jrodgers@figma.com>
* add test case
Signed-off-by: Jordan Rodgers <jrodgers@figma.com>
* address test comments
Signed-off-by: Jordan Rodgers <jrodgers@figma.com>
---------
Signed-off-by: Jordan Rodgers <jrodgers@figma.com>
The linter settings key was incorrectly named "linter-settings" instead of
"linters-settings", preventing proper parsing of goimports configuration.
This fixes the local-prefixes setting for import organization.
All affected files have been automatically reformatted to comply with the
now-active goimports rules for import ordering and grouping.
Signed-off-by: Ville Vesilehto <ville@vesilehto.fi>
* fix: make selector immutable
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix: make selector immutable
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix: make selector optional for workloadRef
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix: move recorder event to after experiment reconcilation, fixes#4021
Signed-off-by: Roy Arnon <roy.a@taboola.com>
* Add Taboola to the user list
---------
Signed-off-by: Roy Arnon <roy.a@taboola.com>
Co-authored-by: Zach Aller <zachaller@users.noreply.github.com>
* fix: rollout should timeout when paused
Signed-off-by: Li Wang <li.wang3@fmr.com>
* chore: add test cases for Rollout timeout when paused or aborted
Signed-off-by: Li Wang <li.wang3@fmr.com>
---------
Signed-off-by: Li Wang <li.wang3@fmr.com>
* test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add comments
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* comments
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* no need to check length, same in both versions
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add active filter back
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* rename vars add comments
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* remove comment
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
add check for overall pause condition to indefinite step
Signed-off-by: Miles <miles.wilson@wolterskluwer.com>
Co-authored-by: Miles <miles.wilson@wolterskluwer.com>
* feat(controller): enable pprof profiling
Signed-off-by: John Wood <jmw.home@gmail.com>
* wip
Signed-off-by: John Wood <jmw.home@gmail.com>
* Consolidate --enable-pprof and --pprof-port into single config variable
Signed-off-by: John Wood <jmw.home@gmail.com>
---------
Signed-off-by: John Wood <jmw.home@gmail.com>
The current code creates a new http.Transport for each http.Client that is
created, which leads to a leak in TCP connections due to keep-alive.
Instead, reuse the same http.Transport between requests. According to the
http.Transport docs, this is safe for concurrent use.
Signed-off-by: Kevin Ji <1146876+kevinji@users.noreply.github.com>
* feat: add rollout-transform-2023-10-09.yaml which has been adapted for kustomize v5
Signed-off-by: Jethro Lee <jethro.lee@a-bly.com>
* Rename to rollout-transform-kustomize-v5.yaml
Signed-off-by: Hidetake Iwata <int128@gmail.com>
* Add link to doc
Signed-off-by: Hidetake Iwata <int128@gmail.com>
---------
Signed-off-by: Jethro Lee <jethro.lee@a-bly.com>
Signed-off-by: Hidetake Iwata <int128@gmail.com>
Co-authored-by: Jethro Lee <jethro.lee@a-bly.com>
* fix(controller): use the stableRS from the rollout context rather than inferring it from the active selector, to deal with the edge case where the stableRS != activeRS during analysis templates
Signed-off-by: ben.minter <ben.minter@treatwell.com>
* fix(controller): update tests which were relying on this bug(?)
Signed-off-by: ben.minter <ben.minter@treatwell.com>
* fix(controller): add clarity to comment in the case there is no stableRS
Signed-off-by: ben.minter <ben.minter@treatwell.com>
* fix(controller): add a test to assert that the stablers is not scaled by the reconiliation on start, by checking the log
Signed-off-by: ben.minter <ben.minter@treatwell.com>
---------
Signed-off-by: ben.minter <ben.minter@treatwell.com>
* make sure config is used and only send merged coverage
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* checkout repo to get codecov config
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* use folder not file
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* disable search
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* switch merged output format
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* stop controller before upload
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* stop controller
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* stop controller
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* only stop on latest
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* print controller pids
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix erro
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add ls
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* kill correct process
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add proper cover for unit to ues with merge
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* upload directory now
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* seperate test reporting
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix file name path
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* refactor according to suggestions
Signed-off-by: cyrilico <19289022+cyrilico@users.noreply.github.com>
* codegen
Signed-off-by: cyrilico <19289022+cyrilico@users.noreply.github.com>
* missing codegen
Signed-off-by: cyrilico <19289022+cyrilico@users.noreply.github.com>
* Update specification.md
Signed-off-by: cyrilico <19289022+cyrilico@users.noreply.github.com>
* further clarify when to use new field
Signed-off-by: cyrilico <19289022+cyrilico@users.noreply.github.com>
---------
Signed-off-by: cyrilico <19289022+cyrilico@users.noreply.github.com>
* first pass at coverage for e2e
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* change folder names
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* only upload latest e2e results
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* change name of step
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix matrix name
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* rename files
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add directory
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* use correct upload name
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* move event file
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* bad move of event_file
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix uncomment
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* only run on testing workflow
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* remove events from go workflow
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* use new download metho
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* remove specific file
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* change workflow name
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* remove double upload
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* Datadog: explicitly set aggregator to last
the field is required by API and we currently leave it empty string
Signed-off-by: Alex Eftimie <alex.eftimie@getyourguide.com>
* add unit tests
Signed-off-by: Alex Eftimie <alex.eftimie@getyourguide.com>
---------
Signed-off-by: Alex Eftimie <alex.eftimie@getyourguide.com>
* Ensure that BackgroundAnalysisRun does not run when rolling back within RollbackWindow
Signed-off-by: Alex Dunn <adunn@sofi.org>
* Fix linting
Signed-off-by: Alex Dunn <adunn@sofi.org>
---------
Signed-off-by: Alex Dunn <adunn@sofi.org>
* fix: when Rollout has pingpong and stable/canary service defined, GetStableAndCanaryServices returns based on isPingpongPreferred. Only when it is ALB controller, then isPringpongPreferred is true.
Signed-off-by: mayz985 <may_zhang@intuit.com>
* fix lint error
Signed-off-by: mayz985 <may_zhang@intuit.com>
* added e2e
Signed-off-by: mayz985 <may_zhang@intuit.com>
---------
Signed-off-by: mayz985 <may_zhang@intuit.com>
* fix: verify the weight of the alb at the end of the rollout when we auto set max weight
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add unit test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* refactor add unit test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* Trigger Build
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* Trigger Build
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* block reconcile
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add tests
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* rename test and cleanup un-need logic check
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add codecov token
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fail if we do not upload
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix: fallback to patch on scale conflict
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
fix: switch to retry logic
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
lint
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
retry experiments
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
remove TODO
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
remove accidental add
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
remove accidental add
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
add retry to setting revision
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
chore(deps): bump slsa-framework/slsa-github-generator from 1.10.0 to 2.0.0 (#3537)
chore(deps): bump slsa-framework/slsa-github-generator
Bumps [slsa-framework/slsa-github-generator](https://github.com/slsa-framework/slsa-github-generator) from 1.10.0 to 2.0.0.
- [Release notes](https://github.com/slsa-framework/slsa-github-generator/releases)
- [Changelog](https://github.com/slsa-framework/slsa-github-generator/blob/main/CHANGELOG.md)
- [Commits](https://github.com/slsa-framework/slsa-github-generator/compare/v1.10.0...v2.0.0)
---
updated-dependencies:
- dependency-name: slsa-framework/slsa-github-generator
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
chore(deps): bump sigstore/cosign-installer from 3.4.0 to 3.5.0 (#3522)
Bumps [sigstore/cosign-installer](https://github.com/sigstore/cosign-installer) from 3.4.0 to 3.5.0.
- [Release notes](https://github.com/sigstore/cosign-installer/releases)
- [Commits](e1523de757...59acb6260d)
---
updated-dependencies:
- dependency-name: sigstore/cosign-installer
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
chore(deps): bump golangci/golangci-lint-action from 4 to 5 (#3540)
Bumps [golangci/golangci-lint-action](https://github.com/golangci/golangci-lint-action) from 4 to 5.
- [Release notes](https://github.com/golangci/golangci-lint-action/releases)
- [Commits](https://github.com/golangci/golangci-lint-action/compare/v4...v5)
---
updated-dependencies:
- dependency-name: golangci/golangci-lint-action
dependency-type: direct:production
update-type: version-update:semver-major
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
docs: provide recommendation for strategies (#3531)
* docs: provide recommendation for strategies
Signed-off-by: Kostis (Codefresh) <39800303+kostis-codefresh@users.noreply.github.com>
* docs: traffic manager clarifications
Signed-off-by: Kostis (Codefresh) <39800303+kostis-codefresh@users.noreply.github.com>
* docs: explain canary with/out traffic manager
Signed-off-by: Kostis (Codefresh) <39800303+kostis-codefresh@users.noreply.github.com>
* docs: add 3 columns on the comparison table
Signed-off-by: Kostis (Codefresh) <39800303+kostis-codefresh@users.noreply.github.com>
---------
Signed-off-by: Kostis (Codefresh) <39800303+kostis-codefresh@users.noreply.github.com>
feat(dashboard): change the color of the current rollout step (#3526)
I feel that having the current (running) step in a orange color is misleading,
as orange usually means warning.
This commit changes the color to the `$argo-running-color`.
Signed-off-by: Alejandro López Sánchez <alejandro.lopez@factorial.co>
chore(deps): bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.37.0 to 1.38.0 (#3525)
chore(deps): bump github.com/aws/aws-sdk-go-v2/service/cloudwatch
Bumps [github.com/aws/aws-sdk-go-v2/service/cloudwatch](https://github.com/aws/aws-sdk-go-v2) from 1.37.0 to 1.38.0.
- [Release notes](https://github.com/aws/aws-sdk-go-v2/releases)
- [Changelog](https://github.com/aws/aws-sdk-go-v2/blob/service/s3/v1.38.0/CHANGELOG.md)
- [Commits](https://github.com/aws/aws-sdk-go-v2/compare/service/s3/v1.37.0...service/s3/v1.38.0)
---
updated-dependencies:
- dependency-name: github.com/aws/aws-sdk-go-v2/service/cloudwatch
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
perform all of set revision actions on retry
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
fix variable
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
add retry counts to log
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
add retry counts to logs
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
clean logs, always dump controller e2e logs
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
lower timeout
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
bump timeout on e2e
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
retry on rollout conflict
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
don't reque on rs changes
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
reque rs
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
bump qps for e2e
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
fix gen-crd
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
switch to patch
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
switch to patch
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
add log
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
move log lines
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
Trigger Build
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
fix one e2e test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
lint
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
add test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
chore(deps): bump actions/setup-go from 5.0.0 to 5.0.1 (#3552)
Bumps [actions/setup-go](https://github.com/actions/setup-go) from 5.0.0 to 5.0.1.
- [Release notes](https://github.com/actions/setup-go/releases)
- [Commits](https://github.com/actions/setup-go/compare/v5.0.0...v5.0.1)
---
updated-dependencies:
- dependency-name: actions/setup-go
dependency-type: direct:production
update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
chore(deps): bump codecov/codecov-action from 4.3.0 to 4.3.1 (#3550)
Bumps [codecov/codecov-action](https://github.com/codecov/codecov-action) from 4.3.0 to 4.3.1.
- [Release notes](https://github.com/codecov/codecov-action/releases)
- [Changelog](https://github.com/codecov/codecov-action/blob/main/CHANGELOG.md)
- [Commits](https://github.com/codecov/codecov-action/compare/v4.3.0...v4.3.1)
---
updated-dependencies:
- dependency-name: codecov/codecov-action
dependency-type: direct:production
update-type: version-update:semver-patch
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
chore(deps): bump google.golang.org/protobuf from 1.33.0 to 1.34.0 (#3548)
Bumps google.golang.org/protobuf from 1.33.0 to 1.34.0.
---
updated-dependencies:
- dependency-name: google.golang.org/protobuf
dependency-type: direct:production
update-type: version-update:semver-minor
...
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
refactor
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
add test for updating rs revision
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
add retry for ephemeral metadata
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
clear some fields
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
add logs
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
refactor into function
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
change log
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
switch rollout update to patch fallback
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
siwtch ephemeral metadata sync to shared function
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
siwtch merge type
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
lint
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
don't update status
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
switch rollout update to not use patch
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
change log
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
switch to small patch
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
some cleanup
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
remove not found rollout removal
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
working setup
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
lint
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
fix test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
small cleanup
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* typo
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* cleanup commented out code
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* Trigger Build
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* only patch rollouts manged fields
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* lint
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix flaky test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix flaky test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* reduce patch size
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* get some logs
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* cleanup
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* improve tests
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* Trigger Build
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add env var to log diff
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* remove expirment rs patch
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* imporve logs
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* use correct variable
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* change env var
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix flaky e2e
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix flaky e2e
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix flaky e2e
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* remove not found rollouts
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* update replica count
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* lint
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* refactor cleanup
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* keep track of UpdatedReplicas on sync
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* some hpa tests and log changes
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* remove update to UpdatedReplicas
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add more test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* undo change
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add comment to flaky tests
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* cleanup Makefile
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* remove test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* use labels
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* remove make file change
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add label to test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* review changes
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* change to TODO
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add extra logging for tests
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* Trigger Build
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add ignore to codecov
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* we always generate patch because we are comparing against emtpy obj
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
I feel that having the current (running) step in a orange color is misleading,
as orange usually means warning.
This commit changes the color to the `$argo-running-color`.
Signed-off-by: Alejandro López Sánchez <alejandro.lopez@factorial.co>
* chore: bump k8s versions
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* chore: remove a few old e2e k8s versions
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
This commit adds two improvements to the Pods view:
* Show spinner (pending status) while the pod is not ready (like ArgoCD UI does)
* Show the `ready` property on the tooltip
Signed-off-by: Alejandro López Sánchez <alejandro.lopez@factorial.co>
* feat: wip ping pong support for istio
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* feat: wip ping pong validation fixes
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add istio ping pong e2e
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add istio ping pong e2e
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* clean up comments
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add ping pong and destRule both configred e2e test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* cleanup not needed test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add docs
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add new test instead of piggy backing of an old one
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* change test name
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add analysisRun to the rollout notification
Signed-off-by: ashutosh16 <11219262+ashutosh16@users.noreply.github.com>
* add analysisRun to the rollout notification
Signed-off-by: ashutosh16 <11219262+ashutosh16@users.noreply.github.com>
* add analysisRun to the rollout notification
Signed-off-by: ashutosh16 <11219262+ashutosh16@users.noreply.github.com>
* add analysisRun to the rollout notification
Signed-off-by: ashutosh16 <11219262+ashutosh16@users.noreply.github.com>
* small changes
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: ashutosh16 <11219262+ashutosh16@users.noreply.github.com>
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
Co-authored-by: Zach Aller <zachaller@users.noreply.github.com>
* add support for the traffic weight > 100.
Signed-off-by: Liming Liu <andyliuliming@outlook.com>
* unit test for the max weight ingress.
Signed-off-by: Liming Liu <andyliuliming@outlook.com>
* unit test for the max weight in canary rollout.
Signed-off-by: Liming Liu <andyliuliming@outlook.com>
* add docs
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add docs
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Liming Liu <andyliuliming@outlook.com>
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
Co-authored-by: Zach Aller <zachaller@users.noreply.github.com>
* added Consul plugin support to website
Signed-off-by: Michael Wilkerson <mwilkerson@hashicorp.com>
* addressed comments
Signed-off-by: Michael Wilkerson <mwilkerson@hashicorp.com>
---------
Signed-off-by: Michael Wilkerson <mwilkerson@hashicorp.com>
* Run: go get github.com/argoproj/notifications-engine@7a069766e95476e1074eeed6145085160e2fec63
Updating and fetch latest notifications-engine dependencies
Signed-off-by: Andre Marcelo-Tanner <drechin@gmail.com>
* Run: go get github.com/argoproj/notifications-engine/pkg/services@v0.4.1-0.20240219110818-7a069766e954
Signed-off-by: Andre Marcelo-Tanner <drechin@gmail.com>
* Replace telegram-bot-api and run go mod tidy
- Update go.mod: github.com/go-telegram-bot-api/telegram-bot-api/v5 => github.com/OvyFlash/telegram-bot-api/v5 v5.0.0-20240108230938-63e5c59035bf
- Ref: https://github.com/argoproj/notifications-engine/pull/265
- Could also be done via go replace --edit
- go mod tidy also ran
Signed-off-by: Andre Marcelo-Tanner <drechin@gmail.com>
* Add strReplaceDocFiles to update strings from default docs
Signed-off-by: Andre Marcelo-Tanner <drechin@gmail.com>
* Run: make docs
Signed-off-by: Andre Marcelo-Tanner <drechin@gmail.com>
* replace <config-map-name> with argo-rollouts-notification-configmap and also replace secret with argocd-notifications-secret
Signed-off-by: Andre Marcelo-Tanner <drechin@gmail.com>
* add Ada company to USERS.md
Signed-off-by: Andre Marcelo-Tanner <drechin@gmail.com>
* chore: update contributing docs with notifications engine section
Signed-off-by: Andre Marcelo-Tanner <drechin@gmail.com>
---------
Signed-off-by: Andre Marcelo-Tanner <drechin@gmail.com>
fix: append weighted destination only when weight is mentioned in experiment template
Signed-off-by: divyansh375 <divyanshsaxena98@gmail.com>
Co-authored-by: divyansh375 <divyanshsaxe@adobe.com>
fix: stuck rollout when rollout is paused
fix: stuck rollout when rollout is paused
fix: stuck rollout when rollout is paused
fix: stuck rollout when rollout is paused
fix: stuck rollout when rollout is paused
fix: stuck rollout when rollout is paused
fix: stuck rollout when rollout is paused
fix: stuck rollout when rollout is paused
fix: stuck rollout when rollout is paused
Signed-off-by: ashutosh16 <11219262+ashutosh16@users.noreply.github.com>
Co-authored-by: asingh51 <ashutosh_singh@intuit.com>
* add exception to `requireCanaryStableServices` to disable validation when using the `hashicorp/consul` plugin
Co-authored-by: Ashwin Venkatesh <ashwin.what@gmail.com>
Signed-off-by: Michael Wilkerson <mwilkerson@hashicorp.com>
* added HashiCorp to USERS.md
Co-authored-by: Ashwin Venkatesh <ashwin.what@gmail.com>
Signed-off-by: Michael Wilkerson <mwilkerson@hashicorp.com>
* modified requireCanaryStableServices to reverse logic
- added test cases for exceptions to requiring checks for Canary/Stable services
- added test cases for verifying errors when Canary/Stable services are missing
Co-authored-by: Ashwin Venkatesh <ashwin.what@gmail.com>
Signed-off-by: Michael Wilkerson <mwilkerson@hashicorp.com>
* addressed comments and added more test cases
Co-authored-by: Ashwin Venkatesh <ashwin.what@gmail.com>
Signed-off-by: Michael Wilkerson <mwilkerson@hashicorp.com>
* modified requireCanaryStableServices to reverse logic
- added test cases for exceptions to requiring checks for Canary/Stable services
- added test cases for verifying errors when Canary/Stable services are missing
Co-authored-by: Ashwin Venkatesh <ashwin.what@gmail.com>
Signed-off-by: Michael Wilkerson <mwilkerson@hashicorp.com>
---------
Signed-off-by: Michael Wilkerson <mwilkerson@hashicorp.com>
Co-authored-by: Ashwin Venkatesh <ashwin.what@gmail.com>
* do not switch service selectors back when using alb due to race between two controllers with pod readiness gates
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* update tests for alb
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* lets not check for readiness instead
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* clean up notes
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix /
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* Add ttlStrategy on AnalysisRun
Signed-off-by: Kevin Qian <kevin.qian@databricks.com>
* Unit test coverage
Signed-off-by: Kevin Qian <kevin.qian@databricks.com>
* Unit test 2
Signed-off-by: Kevin Qian <kevin.qian@databricks.com>
* Regen go proto def
Signed-off-by: Kevin Qian <kevin.qian@databricks.com>
* Doc available from 1.6 -> 1.7
Signed-off-by: Kevin Qian <kevin.qian@databricks.com>
* TtlStrategy -> TTLStrategy
Signed-off-by: Kevin Qian <kevin.qian@databricks.com>
---------
Signed-off-by: Kevin Qian <kevin.qian@databricks.com>
* fix: keep rs inormer updated upon updating labels and annotations
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* give error some context
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* chore: run codegen in 2024
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* chore: remove year from codegen
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* chore: remove year from codegen
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix: fix the rollout stuck when pod/replicas changed together or canary strategy.
Signed-off-by: Liming Liu <andyliuliming@outlook.com>
* add one unit test case for empty canary service.
Signed-off-by: Liming Liu <andyliuliming@outlook.com>
* use rollout status to get the replicaset hash instead of service
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Liming Liu <andyliuliming@outlook.com>
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
Co-authored-by: Liming Liu <andyliuliming@outlook.com>
* fix: canary step analysis run wasn't terminated as keep running after promote action being called
Signed-off-by: oleksandr-codefresh <oleksandr.saulyak@codefresh.io>
* fix unit test: added test case for canary step analysis run wasn't terminated as keep running after promote action being called
Signed-off-by: oleksandr-codefresh <oleksandr.saulyak@codefresh.io>
---------
Signed-off-by: oleksandr-codefresh <oleksandr.saulyak@codefresh.io>
Co-authored-by: pasha-codefresh <pavel@codefresh.io>
chore: leave the validation of setHeaderRoute to the plugin if plugins not empty.
Signed-off-by: Liming Liu <andyliuliming@outlook.com>
Co-authored-by: Ubuntu <andliu@devbox.5xpt1tfa54mehhcinhsnwwrpve.ix.internal.cloudapp.net>
* fix: possibly fix conflict on updates to revision
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* wip
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix one test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix tests
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* cleanup
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* change order
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* change order to match reality
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add comments on exptected actions
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* Bump k8s dependencies to v1.26.0.
This addresses a few CVEs, but was slightly challenging because of some Kubernetes API changes.
In particular, the Ingress type signatures changed. This required some surgery on a function that
wrapped the extensionsv1beta1 Ingress and v1 Ingress types, attempting to provide some compatibility.
The API changes were kind of tough to deal with, but fortunately the only field required by anything else
in this project was the Hostname field, so I changed the function to just normalize the hostnames into
a slice.
Signed-off-by: Dan Lorenc <dlorenc@chainguard.dev>
* Update codegen.
Signed-off-by: Dan Lorenc <dlorenc@chainguard.dev>
* bump the replace deps, and re-run codegen
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* bump to 0.26.11 and possible fix for new crd properties
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* remove local changes
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* switch alb test off of extensions and on to v1
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Dan Lorenc <dlorenc@chainguard.dev>
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
Co-authored-by: Zach Aller <zachaller@users.noreply.github.com>
Automatically scale down Deployment after migrating to Rollout
Signed-off-by: balasoiu <balasoiu@adobe.com>
Co-authored-by: balasoiu <balasoiu@adobe.com>
* fix: for rollouts getting stuck due to bad rs informer updates
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* fix error msg
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* change logic
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* error fmt
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* change if logic
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* add test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* cleanup test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* cleanup test
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* do not double call
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
---------
Signed-off-by: Zach Aller <zachaller@users.noreply.github.com>
* Tests require atleast kustomize v4.5.5, install v5.2.1 if we are using a different version of kustomize
Signed-off-by: Andre Marcelo-Tanner <andre@ada.support>
* revert version upgrade and just rely on docs
Signed-off-by: Andre Marcelo-Tanner <andre@ada.support>
---------
Signed-off-by: Andre Marcelo-Tanner <andre@ada.support>
* feat: Rollouts UI Refresh
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* add test for labels and annotations
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* simplify regex
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* make filters use OR logic
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* add keyboard listener
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* set default display mode to grid
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* set strategy column to left justify
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* add tooltips to view buttons
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* consider unknown status rollouts as needing attention
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* remove duplicate escape key listener
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* group status filters together
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* improve filter logic
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* remove debug logging
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* dont show help on escape
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* properly remove url search params when disabled
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* rename to RolloutGridWidget
Signed-off-by: Philip Clark <philip.clark@iterable.com>
* prevent help menu from loading while searching
Signed-off-by: Philip Clark <philip.clark@iterable.com>
---------
Signed-off-by: Philip Clark <philip.clark@iterable.com>
smi.md: fix typo
Before: "Name of service that sends traffic only to the stable po ds"
After: "Name of service that sends traffic only to the stable pods"
Signed-off-by: Daniel Metz <dmetz@figma.com>
* istio destionationrule subsets enforcement
Signed-off-by: Dennis Nguyen <dnguyen@nextdoor.com>
* add users
Signed-off-by: Dennis Nguyen <dnguyen@nextdoor.com>
* add test case for failure cases
Signed-off-by: Dennis Nguyen <dnguyen@nextdoor.com>
---------
Signed-off-by: Dennis Nguyen <dnguyen@nextdoor.com>
Add a root CONTRIBUTING.md that directs to docs/CONTRIBUTING.md
# Details
- having a `CONTRIBUTING.md` at the root of the repo is a common convention
- I looked at the root of the repo initially, didn't find it, then checked the website, but potential contributors may think it doesn't exist as a result
Shamelessly copied from https://github.com/argoproj/argo-workflows/pull/10969 (thank you @agilgur5)
Signed-off-by: jmeridth <jmeridth@gmail.com>
* Add note in CONTRIBUTING.md that I would have found useful.
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* Fix gen-openapi to be more portable - make sure it includes the GOPATH in the call.
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* Update docs.
* Expand working with v2 information
* Contacted Datadog to get latest info re: v1 deprecation, api limits.
* Add tips about rate limits, using helm for templates
* Add more example templates
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* Update Datadog Analysis Type
* Make Query omitempty since now possible it won't exist
* Add some descriptions
* Add new properties we need for v2
Queries: We can pass in key:query for queries
Formula: Makes formulas using the keys from queries
* Defaults!
Use annotations to declare defaults for some fields. This lets us remove some guard rails from the code itself
Interval: 5m - Move this from code to here
ApiVersion: v1 - Move this from code to here
* Enums!
Much like defaults, having enums lets us make assumptions about the incoming metric so we dont need as many guardrails.
ApiVersion: Enum to restrict to v1 or v2
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* Output of make codegen
Everything looks ok.
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* Pass in metric to provider factory. Validate metric.
Validating the metric on initialization, rather than spread out throughout. You get earlier feedback if you have a bad metric defined. (Not perfect, but there's limitations with our annotation generator for the rules in the crd. eg: If we could use oneOf, we wouldn't need a lot of this validation)
We check all the mutually exclusive props.
The props where one requires another.
We don't have to check for defaults and set them anymore, since they are guaranteed by the crd.
rules:
- ensure we have only query OR queries
- restrict v1 to query only
- make sure you only provide a formula with queries
- make sure multiple queries are accompanied by a formula
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* Remove DefaultApiVersion, remove impossible AnalysisPhaseError
ApiVersion is guaranteed to have value, and the enum ensures its v1/v2 when user provided.
Updated v1 tests to reflect some of these new realities
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* extract urlBuilding from run
run was getting a bit long according to the checks
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* Remove some unnecessary stuff for interval.
It is a straightline to initialize since default is set to 5m for incoming metrics where it is not set.
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* Update createRequest
Split into createRequest v1/v2
v1 : pretty much unchanged. just extracted
v2: support for v2/query/scalar
We don't need all the timeseries. I did some testing fetching both scalar and timeseries, and they pretty much lined up.
Also confirmed with DD: From support ticket with DD: "...I have also tested the scalar api endpoint with the last aggregator as well as the timeseries api endpoint. They do indeed return the same values when retrieving the values via the api endpoints. Observing the time it takes to retrieve the values, they remain relatively the same..."
re: query + v2: Keep backwards compat. if we get in a query, we turn it into a queries object to pass on to requestv2 queries into the QueriesPayload.
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* Handle v2 scalar responses
* update the datadogResponseV2 for scalar values
* handle no results so it has parity with v1 - empty will now usually result in `[]` unless something goes very wrong on dd side
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* update v1 no data tests to better reflect reality
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* update v2 tests
* add some new test cases
* update mock server to handle queries / formulas validation
* update no data tests to reflect reality
* stop all values being the same. it makes it difficult to know find which test case failed. move meaning from comments into the metric name.
* stop using deprecated ioutil
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
* re-codegen
Signed-off-by: zachaller <zachaller@users.noreply.github.com>
* fix lint
Signed-off-by: zachaller <zachaller@users.noreply.github.com>
---------
Signed-off-by: mitchell amihod <4623+meeech@users.noreply.github.com>
Signed-off-by: zachaller <zachaller@users.noreply.github.com>
Co-authored-by: zachaller <zachaller@users.noreply.github.com>
* fix: analysis step should be ignored after promote in case if result was inconclusive
Signed-off-by: pashakostohrys <pavel@codefresh.io>
* fix: analysis step should be ignored after promote in case if result was inconclusive
Signed-off-by: pashakostohrys <pavel@codefresh.io>
---------
Signed-off-by: pashakostohrys <pavel@codefresh.io>
This update ensures documentation and test examples reflect the use
of the newer `patches` method, transitioning away from the deprecated
`patchesStrategicMerge`. This aligns with current best practices and
recommendations from the kustomize project.
Signed-off-by: Daniel Wright <danielwright@bitgo.com>
This commit updates all Kubernetes ingress rules in Argo Rollouts
to use the stable `networking.k8s.io/v1` API, ensuring compatibility
with Kubernetes v1.19+ and leveraging new features available in the
stable version.
Signed-off-by: Daniel Wright <danielwright@bitgo.com>
* fix(canary): skip steps when in rollback window and rs is still active
Resolve#2939
Signed-off-by: Andy Chen <amazingandyyy@gmail.com>
* test(canary): add case where rollback when in window and rs is still active
Signed-off-by: Andy Chen <amazingandyyy@gmail.com>
* test(replicaset): add test case for IsActive function
Signed-off-by: Andy Chen <amazingandyyy@gmail.com>
---------
Signed-off-by: Andy Chen <amazingandyyy@gmail.com>
Co-authored-by: Yohan Belval <ybelval@turo.com>
Co-authored-by: zachaller <zachaller@users.noreply.github.com>
* [ ] Either (a) I've created an [enhancement proposal](https://github.com/argoproj/argo-rollouts/issues/new/choose) and discussed it with the community, (b) this is a bug fix, or (c) this is a chore.
* [ ] The title of the PR is (a) [conventional](https://www.conventionalcommits.org/en/v1.0.0/) with a list of types and scopes found [here](https://github.com/argoproj/argo-rollouts/blob/master/.github/workflows/pr-title-check.yml), (b) states what changed, and (c) suffixes the related issues number. E.g. `"fix(controller): Updates such and such. Fixes #1234"`.
* [ ] I've signed my commits with [DCO](https://github.com/argoproj/argoproj)
* [ ] I've signed my commits with [DCO](https://github.com/argoproj/argoproj/blob/main/community/CONTRIBUTING.md#legal)
* [ ] I have written unit and/or e2e tests for my change. PRs without these are unlikely to be merged.
* [ ] My builds are green. Try syncing with master if they are not.
* [ ] My organization is added to [USERS.md](https://github.com/argoproj/argo-rollouts/blob/master/USERS.md).
* [ ] My organization is added to [USERS.md](https://github.com/argoproj/argo-rollouts/blob/master/USERS.md).
# Note: cannot use env variables to set go-version (https://docs.github.com/en/actions/using-workflows/reusing-workflows#limitations)
go-version:'1.20'
go-version:'1.23'
platforms:linux/amd64,linux/arm64
push:true
target:kubectl-argo-rollouts
@ -44,62 +44,61 @@ jobs:
quay_password:${{ secrets.QUAY_ROBOT_TOKEN }}
controller-image-provenance:
needs:
- controller-image
permissions:
actions:read# for detecting the Github Actions environment.
id-token:write# for creating OIDC tokens for signing.
packages:write# for uploading attestations. (https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/container/README.md#known-issues)
# Must be refernced by a tag. https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/container/README.md#referencing-the-slsa-generator
actions:read# for detecting the Github Actions environment.
id-token:write# for creating OIDC tokens for signing.
packages:write# for uploading attestations. (https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/container/README.md#known-issues)
# Must be refernced by a tag. https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/container/README.md#referencing-the-slsa-generator
actions:read# for detecting the Github Actions environment.
id-token:write# for creating OIDC tokens for signing.
packages:write# for uploading attestations. (https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/container/README.md#known-issues)
# Must be refernced by a tag. https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/container/README.md#referencing-the-slsa-generator
actions:read# for detecting the Github Actions environment.
id-token:write# for creating OIDC tokens for signing.
packages:write# for uploading attestations. (https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/container/README.md#known-issues)
# Must be refernced by a tag. https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/container/README.md#referencing-the-slsa-generator
id-token:write# Needed for provenance signing and ID
contents:write# Needed for release uploads
# Must be refernced by a tag. https://github.com/slsa-framework/slsa-github-generator/blob/main/internal/builders/container/README.md#referencing-the-slsa-generator
# use separate workflow to support fork repositories and dependabot branches when publishing test results: see https://github.com/EnricoMi/publish-unit-test-result-action#support-fork-repositories-and-dependabot-branches
name:Test Results
name:Testing Results
on:
workflow_run:
workflows:["E2E Tests","Go"]
workflows:["Testing"]
types:
- completed
permissions:{}
@ -19,27 +19,31 @@ jobs:
actions:read
steps:
- name:Download and Extract Artifacts
# TODO repace with native actions/download-artifact once it supports downloading from another workflow: https://github.com/actions/download-artifact/issues/3
stale-issue-message:'This issue is stale because it has awaiting-response label for 5 days with no activity. Remove stale label or comment or this will be closed in 5 days.'
* check ephemeral metadata is set before delete ([#4089](https://github.com/argoproj/argo-rollouts/issues/4089))
* correct typo in linter settings key name ([#4094](https://github.com/argoproj/argo-rollouts/issues/4094))
* loop when paused and completed ([#4134](https://github.com/argoproj/argo-rollouts/issues/4134))
* nil pointer on logging ([#4127](https://github.com/argoproj/argo-rollouts/issues/4127))
* Upgrade go-retryablehttp to v0.7.7 ([#3743](https://github.com/argoproj/argo-rollouts/issues/3743))
* **controller:** rollout stuck in `Progressing`. fixes [#3988](https://github.com/argoproj/argo-rollouts/issues/3988) ([#4072](https://github.com/argoproj/argo-rollouts/issues/4072))
* **dashboard:** Revert react-scripts upgrade due to performance regression. Fixes [#4122](https://github.com/argoproj/argo-rollouts/issues/4122) ([#4166](https://github.com/argoproj/argo-rollouts/issues/4166))
* **metricprovider:** not require address in kubernetes secret for Datadog. Fixes [#4103](https://github.com/argoproj/argo-rollouts/issues/4103) ([#4145](https://github.com/argoproj/argo-rollouts/issues/4145))
* code coverage for e2e ([#3740](https://github.com/argoproj/argo-rollouts/issues/3740))
* use codecov config and only send merged coverage file ([#3751](https://github.com/argoproj/argo-rollouts/issues/3751))
* Add Cloudflare to users ([#3768](https://github.com/argoproj/argo-rollouts/issues/3768))
* capitalize AS in Dockerfile ([#3781](https://github.com/argoproj/argo-rollouts/issues/3781))
* move ReplicaSet creation and Rollout validation earlier during the reconciliation process. ([#3657](https://github.com/argoproj/argo-rollouts/issues/3657))
* Add Trustly to USERS.md ([#3837](https://github.com/argoproj/argo-rollouts/issues/3837))
* **deps:** bump docker/setup-buildx-action from 3.4.0 to 3.5.0 ([#3738](https://github.com/argoproj/argo-rollouts/issues/3738))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.42.2 to 1.42.3 ([#3923](https://github.com/argoproj/argo-rollouts/issues/3923))
* **deps:** bump github.com/newrelic/newrelic-client-go/v2 from 2.48.2 to 2.50.1 ([#3924](https://github.com/argoproj/argo-rollouts/issues/3924))
* **deps:** bump softprops/action-gh-release from 2.0.8 to 2.0.9 ([#3928](https://github.com/argoproj/argo-rollouts/issues/3928))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.38 to 1.28.1 ([#3917](https://github.com/argoproj/argo-rollouts/issues/3917))
* **deps:** bump github.com/hashicorp/go-plugin from 1.6.1 to 1.6.2 ([#3908](https://github.com/argoproj/argo-rollouts/issues/3908))
* **deps:** bump actions/setup-go from 5.0.2 to 5.1.0 ([#3912](https://github.com/argoproj/argo-rollouts/issues/3912))
* **deps:** bump github.com/aws/aws-sdk-go-v2 from 1.32.2 to 1.32.3 ([#3919](https://github.com/argoproj/argo-rollouts/issues/3919))
* **deps:** bump github.com/newrelic/newrelic-client-go/v2 from 2.50.1 to 2.51.3 ([#3939](https://github.com/argoproj/argo-rollouts/issues/3939))
* **deps:** bump google.golang.org/grpc from 1.66.2 to 1.67.1 ([#3903](https://github.com/argoproj/argo-rollouts/issues/3903))
* **deps:** bump docker/setup-buildx-action from 3.6.1 to 3.7.1 ([#3876](https://github.com/argoproj/argo-rollouts/issues/3876))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.40.8 to 1.42.2 ([#3901](https://github.com/argoproj/argo-rollouts/issues/3901))
* **deps:** bump github.com/aws/smithy-go from 1.21.0 to 1.22.0 ([#3885](https://github.com/argoproj/argo-rollouts/issues/3885))
* **deps:** bump github.com/aws/aws-sdk-go-v2 from 1.31.0 to 1.32.2 ([#3886](https://github.com/argoproj/argo-rollouts/issues/3886))
* **deps:** bump google.golang.org/protobuf from 1.34.2 to 1.35.1 ([#3887](https://github.com/argoproj/argo-rollouts/issues/3887))
* **deps:** bump golang.org/x/oauth2 from 0.22.0 to 0.23.0 ([#3841](https://github.com/argoproj/argo-rollouts/issues/3841))
* **deps:** bump codecov/codecov-action from 4.5.0 to 4.6.0 ([#3865](https://github.com/argoproj/argo-rollouts/issues/3865))
* **deps:** bump github.com/newrelic/newrelic-client-go/v2 from 2.45.0 to 2.48.2 ([#3874](https://github.com/argoproj/argo-rollouts/issues/3874))
* **deps:** bump sigstore/cosign-installer from 3.6.0 to 3.7.0 ([#3875](https://github.com/argoproj/argo-rollouts/issues/3875))
* **deps:** bump docker/build-push-action from 6.8.0 to 6.9.0 ([#3863](https://github.com/argoproj/argo-rollouts/issues/3863))
* **deps:** bump docker/build-push-action from 6.7.0 to 6.8.0 ([#3860](https://github.com/argoproj/argo-rollouts/issues/3860))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.33 to 1.27.38 ([#3851](https://github.com/argoproj/argo-rollouts/issues/3851))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.40.5 to 1.40.8 ([#3838](https://github.com/argoproj/argo-rollouts/issues/3838))
* **deps:** bump github.com/newrelic/newrelic-client-go/v2 from 2.43.1 to 2.45.0 ([#3829](https://github.com/argoproj/argo-rollouts/issues/3829))
* **deps:** bump google.golang.org/grpc from 1.65.0 to 1.66.2 ([#3831](https://github.com/argoproj/argo-rollouts/issues/3831))
* **deps:** bump softprops/action-gh-release from 2.0.9 to 2.1.0 ([#3938](https://github.com/argoproj/argo-rollouts/issues/3938))
* **deps:** bump peter-evans/create-pull-request from 6 to 7 ([#3819](https://github.com/argoproj/argo-rollouts/issues/3819))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.31 to 1.27.33 ([#3822](https://github.com/argoproj/argo-rollouts/issues/3822))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.30 to 1.27.31 ([#3807](https://github.com/argoproj/argo-rollouts/issues/3807))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.40.3 to 1.40.5 ([#3808](https://github.com/argoproj/argo-rollouts/issues/3808))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.27 to 1.27.30 ([#3804](https://github.com/argoproj/argo-rollouts/issues/3804))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.42.3 to 1.42.4 ([#3935](https://github.com/argoproj/argo-rollouts/issues/3935))
* **deps:** bump github.com/newrelic/newrelic-client-go/v2 from 2.41.2 to 2.43.1 ([#3793](https://github.com/argoproj/argo-rollouts/issues/3793))
* **deps:** bump github.com/aws/smithy-go from 1.20.3 to 1.20.4 ([#3794](https://github.com/argoproj/argo-rollouts/issues/3794))
* **deps:** bump docker/build-push-action from 6.6.1 to 6.7.0 ([#3791](https://github.com/argoproj/argo-rollouts/issues/3791))
* **deps:** bump github.com/influxdata/influxdb-client-go/v2 from 2.13.0 to 2.14.0 ([#3786](https://github.com/argoproj/argo-rollouts/issues/3786))
* **deps:** bump github.com/aws/aws-sdk-go-v2 from 1.32.3 to 1.32.4 ([#3934](https://github.com/argoproj/argo-rollouts/issues/3934))
* **deps:** bump docker/build-push-action from 6.5.0 to 6.6.1 ([#3776](https://github.com/argoproj/argo-rollouts/issues/3776))
* **deps:** bump sigstore/cosign-installer from 3.5.0 to 3.6.0 ([#3777](https://github.com/argoproj/argo-rollouts/issues/3777))
* **deps:** bump golang.org/x/oauth2 from 0.21.0 to 0.22.0 ([#3766](https://github.com/argoproj/argo-rollouts/issues/3766))
* **deps:** bump docker/build-push-action from 6.9.0 to 6.10.0 ([#3963](https://github.com/argoproj/argo-rollouts/issues/3963))
* **deps:** bump docker/setup-buildx-action from 3.5.0 to 3.6.1 ([#3755](https://github.com/argoproj/argo-rollouts/issues/3755))
* **deps:** bump google.golang.org/protobuf from 1.35.1 to 1.35.2 ([#3950](https://github.com/argoproj/argo-rollouts/issues/3950))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.26 to 1.27.27 ([#3732](https://github.com/argoproj/argo-rollouts/issues/3732))
* **deps:** bump softprops/action-gh-release from 2.0.6 to 2.0.8 ([#3733](https://github.com/argoproj/argo-rollouts/issues/3733))
* **deps:** bump golang.org/x/oauth2 from 0.23.0 to 0.24.0 ([#3949](https://github.com/argoproj/argo-rollouts/issues/3949))
* **deps:** bump docker/setup-qemu-action from 3.1.0 to 3.2.0 ([#3736](https://github.com/argoproj/argo-rollouts/issues/3736))
* **deps:** bump docker/build-push-action from 6.4.0 to 6.5.0 ([#3737](https://github.com/argoproj/argo-rollouts/issues/3737))
* **deps:** bump codecov/codecov-action from 4.6.0 to 5.0.7 ([#3961](https://github.com/argoproj/argo-rollouts/issues/3961))
* **deps:** bump docker/login-action from 3.2.0 to 3.3.0 ([#3739](https://github.com/argoproj/argo-rollouts/issues/3739))
* **deps:** bump docker/build-push-action from 6.3.0 to 6.4.0 ([#3723](https://github.com/argoproj/argo-rollouts/issues/3723))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.24 to 1.27.26 ([#3717](https://github.com/argoproj/argo-rollouts/issues/3717))
* **deps:** bump actions/setup-go from 5.0.1 to 5.0.2 ([#3716](https://github.com/argoproj/argo-rollouts/issues/3716))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.40.1 to 1.40.3 ([#3719](https://github.com/argoproj/argo-rollouts/issues/3719))
* **deps:** bump docker/setup-qemu-action from 3.0.0 to 3.1.0 ([#3696](https://github.com/argoproj/argo-rollouts/issues/3696))
* **deps:** bump docker/build-push-action from 6.2.0 to 6.3.0 ([#3697](https://github.com/argoproj/argo-rollouts/issues/3697))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.23 to 1.27.24 ([#3698](https://github.com/argoproj/argo-rollouts/issues/3698))
* **deps:** bump docker/setup-buildx-action from 3.3.0 to 3.4.0 ([#3705](https://github.com/argoproj/argo-rollouts/issues/3705))
* **deps:** bump google.golang.org/grpc from 1.64.0 to 1.65.0 ([#3694](https://github.com/argoproj/argo-rollouts/issues/3694))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.22 to 1.27.23 ([#3695](https://github.com/argoproj/argo-rollouts/issues/3695))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.28.1 to 1.28.6 ([#3981](https://github.com/argoproj/argo-rollouts/issues/3981))
* **deps:** bump github.com/aws/smithy-go from 1.20.2 to 1.20.3 ([#3685](https://github.com/argoproj/argo-rollouts/issues/3685))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.38.7 to 1.40.1 ([#3687](https://github.com/argoproj/argo-rollouts/issues/3687))
* **deps:** bump softprops/action-gh-release from 2.0.5 to 2.0.6 ([#3656](https://github.com/argoproj/argo-rollouts/issues/3656))
* **deps:** bump docker/build-push-action from 6.1.0 to 6.2.0 ([#3676](https://github.com/argoproj/argo-rollouts/issues/3676))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.19 to 1.27.22 ([#3680](https://github.com/argoproj/argo-rollouts/issues/3680))
* **deps:** bump docker/build-push-action from 6.0.2 to 6.1.0 ([#3662](https://github.com/argoproj/argo-rollouts/issues/3662))
* **deps:** bump docker/build-push-action from 6.0.0 to 6.0.2 ([#3659](https://github.com/argoproj/argo-rollouts/issues/3659))
* **deps:** bump google.golang.org/grpc from 1.67.1 to 1.68.1 ([#3979](https://github.com/argoproj/argo-rollouts/issues/3979))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.18 to 1.27.19 ([#3646](https://github.com/argoproj/argo-rollouts/issues/3646))
* **deps:** bump docker/build-push-action from 5.4.0 to 6.0.0 ([#3644](https://github.com/argoproj/argo-rollouts/issues/3644))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.38.6 to 1.38.7 ([#3647](https://github.com/argoproj/argo-rollouts/issues/3647))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.42.4 to 1.43.3 ([#3980](https://github.com/argoproj/argo-rollouts/issues/3980))
* **deps:** bump github.com/spf13/cobra from 1.8.0 to 1.8.1 ([#3640](https://github.com/argoproj/argo-rollouts/issues/3640))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.38.0 to 1.38.6 ([#3619](https://github.com/argoproj/argo-rollouts/issues/3619))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.16 to 1.27.18 ([#3625](https://github.com/argoproj/argo-rollouts/issues/3625))
* **deps:** bump google.golang.org/protobuf from 1.34.1 to 1.34.2 ([#3633](https://github.com/argoproj/argo-rollouts/issues/3633))
* **deps:** bump codecov/codecov-action from 4.4.1 to 4.5.0 ([#3634](https://github.com/argoproj/argo-rollouts/issues/3634))
* **deps:** bump docker/build-push-action from 5.3.0 to 5.4.0 ([#3624](https://github.com/argoproj/argo-rollouts/issues/3624))
* **deps:** bump golang.org/x/oauth2 from 0.20.0 to 0.21.0 ([#3631](https://github.com/argoproj/argo-rollouts/issues/3631))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.31.1 to 1.31.3 ([#3620](https://github.com/argoproj/argo-rollouts/issues/3620))
* **deps:** bump actions/setup-go from 5.0.0 to 5.0.1 ([#3552](https://github.com/argoproj/argo-rollouts/issues/3552))
* **deps:** bump github.com/aws/aws-sdk-go-v2 from 1.27.0 to 1.27.2 ([#3621](https://github.com/argoproj/argo-rollouts/issues/3621))
* **deps:** bump docker/login-action from 3.1.0 to 3.2.0 ([#3604](https://github.com/argoproj/argo-rollouts/issues/3604))
* **deps:** bump github.com/hashicorp/go-plugin from 1.6.0 to 1.6.1 ([#3606](https://github.com/argoproj/argo-rollouts/issues/3606))
* **deps:** bump google.golang.org/grpc from 1.63.2 to 1.64.0 ([#3607](https://github.com/argoproj/argo-rollouts/issues/3607))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.30.5 to 1.31.1 ([#3608](https://github.com/argoproj/argo-rollouts/issues/3608))
* **deps:** bump golang.org/x/oauth2 from 0.19.0 to 0.20.0 ([#3554](https://github.com/argoproj/argo-rollouts/issues/3554))
* **deps:** bump golangci/golangci-lint-action from 5 to 6 ([#3556](https://github.com/argoproj/argo-rollouts/issues/3556))
* **deps:** bump google.golang.org/protobuf from 1.34.0 to 1.34.1 ([#3557](https://github.com/argoproj/argo-rollouts/issues/3557))
* **deps:** bump softprops/action-gh-release from 2.0.4 to 2.0.5 ([#3561](https://github.com/argoproj/argo-rollouts/issues/3561))
* **deps:** bump codecov/codecov-action from 4.3.1 to 4.4.1 ([#3588](https://github.com/argoproj/argo-rollouts/issues/3588))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.11 to 1.27.16 ([#3597](https://github.com/argoproj/argo-rollouts/issues/3597))
* **deps:** update golang to 1.23 ([#3987](https://github.com/argoproj/argo-rollouts/issues/3987))
* **deps:** bump google.golang.org/protobuf from 1.33.0 to 1.34.0 ([#3548](https://github.com/argoproj/argo-rollouts/issues/3548))
* **deps:** bump codecov/codecov-action from 4.3.0 to 4.3.1 ([#3550](https://github.com/argoproj/argo-rollouts/issues/3550))
* **deps:** bump codecov/codecov-action from 5.0.7 to 5.1.1 ([#3986](https://github.com/argoproj/argo-rollouts/issues/3986))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.37.0 to 1.38.0 ([#3525](https://github.com/argoproj/argo-rollouts/issues/3525))
* **deps:** bump golangci/golangci-lint-action from 4 to 5 ([#3540](https://github.com/argoproj/argo-rollouts/issues/3540))
* **deps:** bump sigstore/cosign-installer from 3.4.0 to 3.5.0 ([#3522](https://github.com/argoproj/argo-rollouts/issues/3522))
* **deps:** bump slsa-framework/slsa-github-generator from 1.10.0 to 2.0.0 ([#3537](https://github.com/argoproj/argo-rollouts/issues/3537))
* **deps:** bump codecov/codecov-action from 4.2.0 to 4.3.0 ([#3517](https://github.com/argoproj/argo-rollouts/issues/3517))
* **deps:** bump go version to 1.22 ([#3516](https://github.com/argoproj/argo-rollouts/issues/3516))
* **deps:** bump google.golang.org/grpc from 1.63.0 to 1.63.2 ([#3512](https://github.com/argoproj/argo-rollouts/issues/3512))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.10 to 1.27.11 ([#3510](https://github.com/argoproj/argo-rollouts/issues/3510))
* **deps:** bump peaceiris/actions-gh-pages from 3 to 4 ([#3513](https://github.com/argoproj/argo-rollouts/issues/3513))
* **deps:** bump docker/setup-buildx-action from 3.2.0 to 3.3.0 ([#3514](https://github.com/argoproj/argo-rollouts/issues/3514))
* **deps:** bump google.golang.org/grpc from 1.62.1 to 1.63.0 ([#3497](https://github.com/argoproj/argo-rollouts/issues/3497))
* **deps:** bump github.com/prometheus/client_model from 0.6.0 to 0.6.1 ([#3499](https://github.com/argoproj/argo-rollouts/issues/3499))
* **deps:** bump golang.org/x/oauth2 from 0.18.0 to 0.19.0 ([#3506](https://github.com/argoproj/argo-rollouts/issues/3506))
* **deps:** bump codecov/codecov-action from 4.1.1 to 4.2.0 ([#3500](https://github.com/argoproj/argo-rollouts/issues/3500))
* **deps:** bump github.com/stretchr/testify from 1.9.0 to 1.10.0 ([#3985](https://github.com/argoproj/argo-rollouts/issues/3985))
* **controller:** Allow specifying full annotations for nginx canary ingresses. ([#3671](https://github.com/argoproj/argo-rollouts/issues/3671))
* **dashboard:** change the color of the current rollout step ([#3526](https://github.com/argoproj/argo-rollouts/issues/3526))
* **metricprovider:** credentials to download plugin ([#3905](https://github.com/argoproj/argo-rollouts/issues/3905))
* **metricprovider:** add prometheus range query support ([#3704](https://github.com/argoproj/argo-rollouts/issues/3704))
### Fix
* add update verb to ClusterRole permissions for scaleDown feature. Fixes [#3672](https://github.com/argoproj/argo-rollouts/issues/3672) ([#3675](https://github.com/argoproj/argo-rollouts/issues/3675))
* e2e test results processing change key name to run-id ([#3744](https://github.com/argoproj/argo-rollouts/issues/3744))
* Update loader-utils to 2.0.4 ([#3601](https://github.com/argoproj/argo-rollouts/issues/3601))
* remove condition where header routes can stay directed at empty service in preemption ([#3898](https://github.com/argoproj/argo-rollouts/issues/3898))
* add secrets so we can download across workflows ([#3746](https://github.com/argoproj/argo-rollouts/issues/3746))
* rollout should skip timeout when paused ([#3711](https://github.com/argoproj/argo-rollouts/issues/3711))
* check isScalingEvent only on stable and newRS ([#3883](https://github.com/argoproj/argo-rollouts/issues/3883))
* rs conflict with fallback to patch ([#3559](https://github.com/argoproj/argo-rollouts/issues/3559))
* verify the weight of the alb at the end of the rollout ([#3627](https://github.com/argoproj/argo-rollouts/issues/3627))
* stop rollout from entering degraded state during blueGreen pause. Fixes [#3843](https://github.com/argoproj/argo-rollouts/issues/3843) ([#3845](https://github.com/argoproj/argo-rollouts/issues/3845))
* when Rollout has pingpong and stable/canary service defined, only alb traffic management uses pingpong. ([#3628](https://github.com/argoproj/argo-rollouts/issues/3628))
* Add volume for plugin and tmp folder ([#3546](https://github.com/argoproj/argo-rollouts/issues/3546))
* replicaSet not scaled down due to incorrect annotations ([#3762](https://github.com/argoproj/argo-rollouts/issues/3762)) ([#3784](https://github.com/argoproj/argo-rollouts/issues/3784))
* docs site version selector broken ([#3590](https://github.com/argoproj/argo-rollouts/issues/3590))
* **analysis:** explicitly set datadog aggregator to last only on v2 ([#3730](https://github.com/argoproj/argo-rollouts/issues/3730))
* **analysis:** Take RollbackWindow into account when Reconciling Analysis Runs. Fixes [#3669](https://github.com/argoproj/argo-rollouts/issues/3669) ([#3670](https://github.com/argoproj/argo-rollouts/issues/3670))
* **controller:** use the stableRS from the rollout context rather tha… ([#3664](https://github.com/argoproj/argo-rollouts/issues/3664))
* **controller:** weighted experiment validation should allow delegating to trafficRouter plugins ([#3909](https://github.com/argoproj/argo-rollouts/issues/3909))
* **controller:** Corrects the logic of comparing sha256 has. Fixes [#3519](https://github.com/argoproj/argo-rollouts/issues/3519) ([#3520](https://github.com/argoproj/argo-rollouts/issues/3520))
* **controller:** Get the right resourceName for traefik.io.Fixes [#3615](https://github.com/argoproj/argo-rollouts/issues/3615) ([#3759](https://github.com/argoproj/argo-rollouts/issues/3759))
* **controller:** fix race condition in updating ephemeral metadata ([#3975](https://github.com/argoproj/argo-rollouts/issues/3975))
* **dashboard:** Update pod status logic to support native sidecars. Fixes [#3366](https://github.com/argoproj/argo-rollouts/issues/3366) ([#3639](https://github.com/argoproj/argo-rollouts/issues/3639))
* **dashboard:** No redirect loop when running on root. Fixes [#3967](https://github.com/argoproj/argo-rollouts/issues/3967) ([#3968](https://github.com/argoproj/argo-rollouts/issues/3968))
* **dashboard:** parse analysis values with JSON5 to handle NaN. Fixes [#2758](https://github.com/argoproj/argo-rollouts/issues/2758) ([#3801](https://github.com/argoproj/argo-rollouts/issues/3801))
* **dashboard:** analysis modal crashed when value not valid ([#3881](https://github.com/argoproj/argo-rollouts/issues/3881))
* **dashboard:** Cleanup viewcontroller after each request. Fixes [#2095](https://github.com/argoproj/argo-rollouts/issues/2095) ([#3966](https://github.com/argoproj/argo-rollouts/issues/3966))
* **metricprovider:** fix handling null values in datadog ([#3893](https://github.com/argoproj/argo-rollouts/issues/3893))
* **metricprovider:** reuse http.Transport for http.Client ([#3780](https://github.com/argoproj/argo-rollouts/issues/3780))
* **trafficrouting:** add nil check for desired annotations map in ALB… ([#3853](https://github.com/argoproj/argo-rollouts/issues/3853))
* **trafficrouting:** Fix downtime on initial deployment using Istio DestinationRule Subsets. Fixes [#2507](https://github.com/argoproj/argo-rollouts/issues/2507) ([#3602](https://github.com/argoproj/argo-rollouts/issues/3602))
* replicaSet not scaled down due to incorrect annotations ([#3762](https://github.com/argoproj/argo-rollouts/issues/3762)) ([#3784](https://github.com/argoproj/argo-rollouts/issues/3784))
* add update verb to ClusterRole permissions for scaleDown feature. Fixes [#3672](https://github.com/argoproj/argo-rollouts/issues/3672) ([#3675](https://github.com/argoproj/argo-rollouts/issues/3675))
* **analysis:** explicitly set datadog aggregator to last only on v2 ([#3730](https://github.com/argoproj/argo-rollouts/issues/3730))
* **analysis:** Take RollbackWindow into account when Reconciling Analysis Runs. Fixes [#3669](https://github.com/argoproj/argo-rollouts/issues/3669) ([#3670](https://github.com/argoproj/argo-rollouts/issues/3670))
* **controller:** Get the right resourceName for traefik.io.Fixes [#3615](https://github.com/argoproj/argo-rollouts/issues/3615) ([#3759](https://github.com/argoproj/argo-rollouts/issues/3759))
* **controller:** use the stableRS from the rollout context rather tha… ([#3664](https://github.com/argoproj/argo-rollouts/issues/3664))
* **dashboard:** Update pod status logic to support native sidecars. Fixes [#3366](https://github.com/argoproj/argo-rollouts/issues/3366) ([#3639](https://github.com/argoproj/argo-rollouts/issues/3639))
* **metricprovider:** reuse http.Transport for http.Client ([#3780](https://github.com/argoproj/argo-rollouts/issues/3780))
* verify the weight of the alb at the end of the rollout ([#3627](https://github.com/argoproj/argo-rollouts/issues/3627))
* when Rollout has pingpong and stable/canary service defined, only alb traffic management uses pingpong. ([#3628](https://github.com/argoproj/argo-rollouts/issues/3628))
* add test for reconcileEphemeralMetadata() ([#3163](https://github.com/argoproj/argo-rollouts/issues/3163))
* leave the validation of setHeaderRoute to the plugin when plugins is not empty. ([#2898](https://github.com/argoproj/argo-rollouts/issues/2898))
* fix lint errors reported by golangci-lint ([#3458](https://github.com/argoproj/argo-rollouts/issues/3458))
* fix unit test data races ([#3478](https://github.com/argoproj/argo-rollouts/issues/3478)) ([#3479](https://github.com/argoproj/argo-rollouts/issues/3479))
* added organization to users.md ([#3481](https://github.com/argoproj/argo-rollouts/issues/3481))
* set webpack hashFunction to modern sha256, remove legacy-provider. Fixes [#2609](https://github.com/argoproj/argo-rollouts/issues/2609) ([#3475](https://github.com/argoproj/argo-rollouts/issues/3475))
* remove year from codegen license ([#3282](https://github.com/argoproj/argo-rollouts/issues/3282))
* update follow-redirects to 1.15.5 ([#3314](https://github.com/argoproj/argo-rollouts/issues/3314))
* add logging context around replicaset updates ([#3326](https://github.com/argoproj/argo-rollouts/issues/3326))
* change controller's deploy strategy to RollingUpdate due to leader election ([#3334](https://github.com/argoproj/argo-rollouts/issues/3334))
* Add exception to `requireCanaryStableServices` to disable validation when using the `hashicorp/consul` plugin ([#3339](https://github.com/argoproj/argo-rollouts/issues/3339))
* Update notifications engine to 7a06976 ([#3384](https://github.com/argoproj/argo-rollouts/issues/3384))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.30.4 to 1.30.5 ([#3491](https://github.com/argoproj/argo-rollouts/issues/3491))
* **deps:** bump golang.org/x/oauth2 from 0.17.0 to 0.18.0 ([#3422](https://github.com/argoproj/argo-rollouts/issues/3422))
* **deps:** bump softprops/action-gh-release from 2.0.3 to 2.0.4 ([#3442](https://github.com/argoproj/argo-rollouts/issues/3442))
* **deps:** bump softprops/action-gh-release from 2.0.2 to 2.0.3 ([#3440](https://github.com/argoproj/argo-rollouts/issues/3440))
* **deps:** bump softprops/action-gh-release from 1 to 2 ([#3438](https://github.com/argoproj/argo-rollouts/issues/3438))
* **deps:** bump docker/build-push-action from 5.1.0 to 5.2.0 ([#3439](https://github.com/argoproj/argo-rollouts/issues/3439))
* **deps:** bump docker/setup-buildx-action from 3.1.0 to 3.2.0 ([#3449](https://github.com/argoproj/argo-rollouts/issues/3449))
* **deps:** bump google.golang.org/grpc from 1.62.0 to 1.62.1 ([#3426](https://github.com/argoproj/argo-rollouts/issues/3426))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.4 to 1.27.5 ([#3421](https://github.com/argoproj/argo-rollouts/issues/3421))
* **deps:** bump github.com/stretchr/testify from 1.8.4 to 1.9.0 ([#3419](https://github.com/argoproj/argo-rollouts/issues/3419))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.0 to 1.27.4 ([#3410](https://github.com/argoproj/argo-rollouts/issues/3410))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.27.0 to 1.30.1 ([#3399](https://github.com/argoproj/argo-rollouts/issues/3399))
* **deps:** bump google.golang.org/grpc from 1.61.0 to 1.62.0 ([#3404](https://github.com/argoproj/argo-rollouts/issues/3404))
* **deps:** bump docker/setup-buildx-action from 3.0.0 to 3.1.0 ([#3406](https://github.com/argoproj/argo-rollouts/issues/3406))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.33.0 to 1.36.1 ([#3400](https://github.com/argoproj/argo-rollouts/issues/3400))
* **deps:** bump codecov/codecov-action from 4.0.1 to 4.1.0 ([#3403](https://github.com/argoproj/argo-rollouts/issues/3403))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.30.1 to 1.30.3 ([#3447](https://github.com/argoproj/argo-rollouts/issues/3447))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.26.6 to 1.27.0 ([#3368](https://github.com/argoproj/argo-rollouts/issues/3368))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.32.2 to 1.33.0 ([#3363](https://github.com/argoproj/argo-rollouts/issues/3363))
* **deps:** bump docker/login-action from 3.0.0 to 3.1.0 ([#3443](https://github.com/argoproj/argo-rollouts/issues/3443))
* **deps:** bump golang.org/x/oauth2 from 0.16.0 to 0.17.0 ([#3357](https://github.com/argoproj/argo-rollouts/issues/3357))
* **deps:** bump golangci/golangci-lint-action from 3 to 4 ([#3359](https://github.com/argoproj/argo-rollouts/issues/3359))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.26.7 to 1.27.0 ([#3341](https://github.com/argoproj/argo-rollouts/issues/3341))
* **deps:** bump peter-evans/create-pull-request from 5 to 6 ([#3342](https://github.com/argoproj/argo-rollouts/issues/3342))
* **deps:** bump sigstore/cosign-installer from 3.3.0 to 3.4.0 ([#3343](https://github.com/argoproj/argo-rollouts/issues/3343))
* **deps:** bump codecov/codecov-action from 3.1.5 to 4.0.1 ([#3347](https://github.com/argoproj/argo-rollouts/issues/3347))
* **deps:** bump github.com/evanphx/json-patch/v5 from 5.8.1 to 5.9.0 ([#3335](https://github.com/argoproj/argo-rollouts/issues/3335))
* **deps:** bump docker/build-push-action from 5.2.0 to 5.3.0 ([#3448](https://github.com/argoproj/argo-rollouts/issues/3448))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.26.5 to 1.26.6 ([#3322](https://github.com/argoproj/argo-rollouts/issues/3322))
* **deps:** bump github.com/evanphx/json-patch/v5 from 5.8.0 to 5.8.1 ([#3312](https://github.com/argoproj/argo-rollouts/issues/3312))
* **deps:** bump codecov/codecov-action from 3.1.4 to 3.1.5 ([#3330](https://github.com/argoproj/argo-rollouts/issues/3330))
* **deps:** bump slsa-framework/slsa-github-generator from 1.9.0 to 1.9.1 ([#3456](https://github.com/argoproj/argo-rollouts/issues/3456))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.36.1 to 1.36.3 ([#3452](https://github.com/argoproj/argo-rollouts/issues/3452))
* **deps:** bump google.golang.org/grpc from 1.60.1 to 1.61.0 ([#3325](https://github.com/argoproj/argo-rollouts/issues/3325))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.26.4 to 1.26.5 ([#3319](https://github.com/argoproj/argo-rollouts/issues/3319))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.26.3 to 1.26.4 ([#3313](https://github.com/argoproj/argo-rollouts/issues/3313))
* **deps:** bump actions/cache from 3 to 4 ([#3315](https://github.com/argoproj/argo-rollouts/issues/3315))
* **deps:** bump slsa-framework/slsa-github-generator from 1.9.1 to 1.10.0 ([#3462](https://github.com/argoproj/argo-rollouts/issues/3462))
* **deps:** bump github.com/evanphx/json-patch/v5 from 5.7.0 to 5.8.0 ([#3309](https://github.com/argoproj/argo-rollouts/issues/3309))
* **deps:** bump golang.org/x/oauth2 from 0.15.0 to 0.16.0 ([#3294](https://github.com/argoproj/argo-rollouts/issues/3294))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.32.1 to 1.32.2 ([#3288](https://github.com/argoproj/argo-rollouts/issues/3288))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.26.2 to 1.26.3 ([#3289](https://github.com/argoproj/argo-rollouts/issues/3289))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.26.6 to 1.26.7 ([#3290](https://github.com/argoproj/argo-rollouts/issues/3290))
* **deps:** bump github.com/aws/aws-sdk-go-v2 from 1.24.0 to 1.24.1 ([#3291](https://github.com/argoproj/argo-rollouts/issues/3291))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.30.3 to 1.30.4 ([#3461](https://github.com/argoproj/argo-rollouts/issues/3461))
* **deps:** bump google.golang.org/protobuf from 1.31.0 to 1.32.0 ([#3273](https://github.com/argoproj/argo-rollouts/issues/3273))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.26.1 to 1.26.2 ([#3268](https://github.com/argoproj/argo-rollouts/issues/3268))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.26.5 to 1.26.6 ([#3269](https://github.com/argoproj/argo-rollouts/issues/3269))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.32.0 to 1.32.1 ([#3270](https://github.com/argoproj/argo-rollouts/issues/3270))
* **deps:** bump google.golang.org/grpc from 1.60.0 to 1.60.1 ([#3260](https://github.com/argoproj/argo-rollouts/issues/3260))
* **deps:** bump github/codeql-action from 2 to 3 ([#3252](https://github.com/argoproj/argo-rollouts/issues/3252))
* **deps:** bump actions/upload-artifact from 3 to 4 ([#3255](https://github.com/argoproj/argo-rollouts/issues/3255))
* **deps:** bump sigstore/cosign-installer from 3.2.0 to 3.3.0 ([#3245](https://github.com/argoproj/argo-rollouts/issues/3245))
* **deps:** bump google.golang.org/grpc from 1.59.0 to 1.60.0 ([#3246](https://github.com/argoproj/argo-rollouts/issues/3246))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.26.0 to 1.26.1 ([#3241](https://github.com/argoproj/argo-rollouts/issues/3241))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.26.4 to 1.26.5 ([#3240](https://github.com/argoproj/argo-rollouts/issues/3240))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.31.4 to 1.32.0 ([#3239](https://github.com/argoproj/argo-rollouts/issues/3239))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.25.12 to 1.26.0 ([#3236](https://github.com/argoproj/argo-rollouts/issues/3236))
* **deps:** bump codecov/codecov-action from 4.1.0 to 4.1.1 ([#3476](https://github.com/argoproj/argo-rollouts/issues/3476))
* **deps:** bump github.com/influxdata/influxdb-client-go/v2 from 2.12.4 to 2.13.0 ([#3217](https://github.com/argoproj/argo-rollouts/issues/3217))
* **deps:** bump actions/stale from 8 to 9 ([#3232](https://github.com/argoproj/argo-rollouts/issues/3232))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.31.3 to 1.31.4 ([#3235](https://github.com/argoproj/argo-rollouts/issues/3235))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.26.3 to 1.26.4 ([#3234](https://github.com/argoproj/argo-rollouts/issues/3234))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.25.11 to 1.25.12 ([#3230](https://github.com/argoproj/argo-rollouts/issues/3230))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.31.2 to 1.31.3 ([#3226](https://github.com/argoproj/argo-rollouts/issues/3226))
* **deps:** bump actions/setup-python from 4 to 5 ([#3227](https://github.com/argoproj/argo-rollouts/issues/3227))
* **deps:** bump actions/setup-go from 4.1.0 to 5.0.0 ([#3228](https://github.com/argoproj/argo-rollouts/issues/3228))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.26.2 to 1.26.3 ([#3229](https://github.com/argoproj/argo-rollouts/issues/3229))
* **deps:** Bump k8s dependencies to v1.26.11 ([#3211](https://github.com/argoproj/argo-rollouts/issues/3211))
* **deps:** bump argo-ui and fix browser console errors ([#3212](https://github.com/argoproj/argo-rollouts/issues/3212))
* **deps:** bump docker/build-push-action from 5.0.0 to 5.1.0 ([#3178](https://github.com/argoproj/argo-rollouts/issues/3178))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.25.10 to 1.25.11 ([#3206](https://github.com/argoproj/argo-rollouts/issues/3206))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.26.1 to 1.26.2 ([#3207](https://github.com/argoproj/argo-rollouts/issues/3207))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.31.1 to 1.31.2 ([#3208](https://github.com/argoproj/argo-rollouts/issues/3208))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.30.5 to 1.31.1 ([#3201](https://github.com/argoproj/argo-rollouts/issues/3201))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.25.2 to 1.26.1 ([#3203](https://github.com/argoproj/argo-rollouts/issues/3203))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.25.8 to 1.25.10 ([#3204](https://github.com/argoproj/argo-rollouts/issues/3204))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.25.5 to 1.25.8 ([#3191](https://github.com/argoproj/argo-rollouts/issues/3191))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.24.3 to 1.25.2 ([#3192](https://github.com/argoproj/argo-rollouts/issues/3192))
* **deps:** bump golang.org/x/oauth2 from 0.13.0 to 0.15.0 ([#3187](https://github.com/argoproj/argo-rollouts/issues/3187))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.30.3 to 1.30.5 ([#3193](https://github.com/argoproj/argo-rollouts/issues/3193))
* **deps:** bump github.com/antonmedv/expr from 1.15.4 to 1.15.5 ([#3186](https://github.com/argoproj/argo-rollouts/issues/3186))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.30.1 to 1.30.3 ([#3179](https://github.com/argoproj/argo-rollouts/issues/3179))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.24.0 to 1.24.3 ([#3180](https://github.com/argoproj/argo-rollouts/issues/3180))
* **deps:** bump github.com/influxdata/influxdb-client-go/v2 from 2.12.3 to 2.12.4 ([#3150](https://github.com/argoproj/argo-rollouts/issues/3150))
* **deps:** bump github.com/antonmedv/expr from 1.15.3 to 1.15.4 ([#3184](https://github.com/argoproj/argo-rollouts/issues/3184))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.23.0 to 1.25.5 ([#3183](https://github.com/argoproj/argo-rollouts/issues/3183))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.30.0 to 1.30.1 ([#3166](https://github.com/argoproj/argo-rollouts/issues/3166))
* **deps:** bump github.com/hashicorp/go-plugin from 1.5.2 to 1.6.0 ([#3167](https://github.com/argoproj/argo-rollouts/issues/3167))
* **deps:** update golang to 1.21 ([#3482](https://github.com/argoproj/argo-rollouts/issues/3482))
* **deps:** bump github.com/bombsimon/logrusr/v4 from 4.0.0 to 4.1.0 ([#3151](https://github.com/argoproj/argo-rollouts/issues/3151))
* **deps:** bump github.com/spf13/cobra from 1.7.0 to 1.8.0 ([#3152](https://github.com/argoproj/argo-rollouts/issues/3152))
* **deps:** bump sigstore/cosign-installer from 3.1.2 to 3.2.0 ([#3158](https://github.com/argoproj/argo-rollouts/issues/3158))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.22.0 to 1.23.0 ([#3161](https://github.com/argoproj/argo-rollouts/issues/3161))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.5 to 1.27.9 ([#3469](https://github.com/argoproj/argo-rollouts/issues/3469))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.28.0 to 1.30.0 ([#3144](https://github.com/argoproj/argo-rollouts/issues/3144))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.22.0 to 1.24.0 ([#3143](https://github.com/argoproj/argo-rollouts/issues/3143))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.20.0 to 1.22.0 ([#3149](https://github.com/argoproj/argo-rollouts/issues/3149))
* **deps:** bump google.golang.org/protobuf from 1.32.0 to 1.33.0 ([#3429](https://github.com/argoproj/argo-rollouts/issues/3429))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.19.1 to 1.20.0 ([#3135](https://github.com/argoproj/argo-rollouts/issues/3135))
* **deps:** bump github.com/aws/aws-sdk-go-v2 from 1.21.2 to 1.22.0 ([#3136](https://github.com/argoproj/argo-rollouts/issues/3136))
* **deps:** bump sigs.k8s.io/yaml from 1.3.0 to 1.4.0 ([#3122](https://github.com/argoproj/argo-rollouts/issues/3122))
* **deps:** bump google.golang.org/grpc from 1.58.3 to 1.59.0 ([#3113](https://github.com/argoproj/argo-rollouts/issues/3113))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.21.6 to 1.22.0 ([#3127](https://github.com/argoproj/argo-rollouts/issues/3127))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.19.0 to 1.19.1 ([#3123](https://github.com/argoproj/argo-rollouts/issues/3123))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.27.9 to 1.28.0 ([#3124](https://github.com/argoproj/argo-rollouts/issues/3124))
* **deps:** bump golang.org/x/oauth2 from 0.10.0 to 0.13.0 ([#3107](https://github.com/argoproj/argo-rollouts/issues/3107))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.45 to 1.19.0 ([#3109](https://github.com/argoproj/argo-rollouts/issues/3109))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.44 to 1.18.45 ([#3101](https://github.com/argoproj/argo-rollouts/issues/3101))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.21.4 to 1.21.6 ([#3100](https://github.com/argoproj/argo-rollouts/issues/3100))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.27.8 to 1.27.9 ([#3102](https://github.com/argoproj/argo-rollouts/issues/3102))
* **deps:** bump github.com/aws/aws-sdk-go-v2 from 1.21.1 to 1.21.2 ([#3103](https://github.com/argoproj/argo-rollouts/issues/3103))
* **deps:** bump github.com/aws/smithy-go from 1.20.1 to 1.20.2 ([#3488](https://github.com/argoproj/argo-rollouts/issues/3488))
* **deps:** bump google.golang.org/grpc from 1.58.2 to 1.58.3 ([#3098](https://github.com/argoproj/argo-rollouts/issues/3098))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.43 to 1.18.44 ([#3099](https://github.com/argoproj/argo-rollouts/issues/3099))
* **deps:** bump github.com/aws/aws-sdk-go-v2 from 1.21.0 to 1.21.1 ([#3085](https://github.com/argoproj/argo-rollouts/issues/3085))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.27.7 to 1.27.8 ([#3086](https://github.com/argoproj/argo-rollouts/issues/3086))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.42 to 1.18.43 ([#3072](https://github.com/argoproj/argo-rollouts/issues/3072))
* **deps:** bump github.com/hashicorp/go-plugin from 1.5.1 to 1.5.2 ([#3056](https://github.com/argoproj/argo-rollouts/issues/3056))
* **deps:** bump github.com/prometheus/common from 0.42.0 to 0.51.1 ([#3468](https://github.com/argoproj/argo-rollouts/issues/3468))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.41 to 1.18.42 ([#3055](https://github.com/argoproj/argo-rollouts/issues/3055))
* **deps:** bump github.com/antonmedv/expr from 1.15.2 to 1.15.3 ([#3046](https://github.com/argoproj/argo-rollouts/issues/3046))
* **deps:** bump docker/setup-qemu-action from 2.2.0 to 3.0.0 ([#3031](https://github.com/argoproj/argo-rollouts/issues/3031))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.39 to 1.18.41 ([#3047](https://github.com/argoproj/argo-rollouts/issues/3047))
* **deps:** bump google.golang.org/grpc from 1.58.0 to 1.58.2 ([#3050](https://github.com/argoproj/argo-rollouts/issues/3050))
* **deps:** bump google.golang.org/grpc from 1.57.0 to 1.58.0 ([#3023](https://github.com/argoproj/argo-rollouts/issues/3023))
* **deps:** bump github.com/evanphx/json-patch/v5 from 5.6.0 to 5.7.0 ([#3030](https://github.com/argoproj/argo-rollouts/issues/3030))
* **deps:** bump docker/metadata-action from 4 to 5 ([#3032](https://github.com/argoproj/argo-rollouts/issues/3032))
* **deps:** bump docker/build-push-action from 4.1.1 to 5.0.0 ([#3033](https://github.com/argoproj/argo-rollouts/issues/3033))
* **deps:** bump docker/setup-buildx-action from 2.10.0 to 3.0.0 ([#3034](https://github.com/argoproj/argo-rollouts/issues/3034))
* **deps:** bump docker/login-action from 2.2.0 to 3.0.0 ([#3035](https://github.com/argoproj/argo-rollouts/issues/3035))
* **deps:** bump github.com/antonmedv/expr from 1.15.1 to 1.15.2 ([#3036](https://github.com/argoproj/argo-rollouts/issues/3036))
* **deps:** bump github.com/aws/aws-sdk-go-v2 from 1.26.0 to 1.26.1 ([#3490](https://github.com/argoproj/argo-rollouts/issues/3490))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.21.3 to 1.21.4 ([#3025](https://github.com/argoproj/argo-rollouts/issues/3025))
* **deps:** bump github.com/hashicorp/go-plugin from 1.5.0 to 1.5.1 ([#3017](https://github.com/argoproj/argo-rollouts/issues/3017))
* **deps:** bump github.com/antonmedv/expr from 1.13.0 to 1.15.1 ([#3024](https://github.com/argoproj/argo-rollouts/issues/3024))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.38 to 1.18.39 ([#3018](https://github.com/argoproj/argo-rollouts/issues/3018))
* **deps:** bump actions/checkout from 3 to 4 ([#3012](https://github.com/argoproj/argo-rollouts/issues/3012))
* **deps:** bump sigstore/cosign-installer from 3.1.1 to 3.1.2 ([#3011](https://github.com/argoproj/argo-rollouts/issues/3011))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.37 to 1.18.38 ([#3002](https://github.com/argoproj/argo-rollouts/issues/3002))
* **deps:** bump github.com/hashicorp/go-plugin from 1.4.10 to 1.5.0 ([#2995](https://github.com/argoproj/argo-rollouts/issues/2995))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.36.3 to 1.37.0 ([#3489](https://github.com/argoproj/argo-rollouts/issues/3489))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.27.9 to 1.27.10 ([#3492](https://github.com/argoproj/argo-rollouts/issues/3492))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.27.6 to 1.27.7 ([#2990](https://github.com/argoproj/argo-rollouts/issues/2990))
* **deps:** bump docker/setup-buildx-action from 2.9.1 to 2.10.0 ([#2994](https://github.com/argoproj/argo-rollouts/issues/2994))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.21.0 to 1.21.3 ([#2977](https://github.com/argoproj/argo-rollouts/issues/2977))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.36 to 1.18.37 ([#2984](https://github.com/argoproj/argo-rollouts/issues/2984))
* **deps:** bump slsa-framework/slsa-github-generator from 1.8.0 to 1.9.0 ([#2983](https://github.com/argoproj/argo-rollouts/issues/2983))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.33 to 1.18.36 ([#2978](https://github.com/argoproj/argo-rollouts/issues/2978))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.27.2 to 1.27.6 ([#2979](https://github.com/argoproj/argo-rollouts/issues/2979))
### Docs
* more best practices ([#3484](https://github.com/argoproj/argo-rollouts/issues/3484))
* typo in BlueGreen ([#3463](https://github.com/argoproj/argo-rollouts/issues/3463))
* minor readability on migration ([#3427](https://github.com/argoproj/argo-rollouts/issues/3427))
* added Consul plugin support to website ([#3362](https://github.com/argoproj/argo-rollouts/issues/3362))
* automatically scale down Deployment after migrating to Rollout ([#3111](https://github.com/argoproj/argo-rollouts/issues/3111))
* Rollouts UI List View Refresh ([#3118](https://github.com/argoproj/argo-rollouts/issues/3118))
* **analysis:** add ttlStrategy on AnalysisRun for garbage collecting stale AnalysisRun automatically ([#3324](https://github.com/argoproj/argo-rollouts/issues/3324))
* **trafficrouting:** use values array for multiple accepted values under same header name ([#2974](https://github.com/argoproj/argo-rollouts/issues/2974))
### Fix
* set formatter for klog logger ([#3493](https://github.com/argoproj/argo-rollouts/issues/3493))
* fix the issue that when max weight is 100000000, and the replicas> 20, the trafficWeightToReplicas will return negative value. ([#3474](https://github.com/argoproj/argo-rollouts/issues/3474))
* analysis step should be ignored after promote ([#3016](https://github.com/argoproj/argo-rollouts/issues/3016))
* job metrics owner ref when using custom job kubeconfig/ns ([#3425](https://github.com/argoproj/argo-rollouts/issues/3425))
* Add the GOPATH to the go-to-protobuf command ([#3022](https://github.com/argoproj/argo-rollouts/issues/3022))
* prevent hot loop when fully promoted rollout is aborted ([#3064](https://github.com/argoproj/argo-rollouts/issues/3064))
* include the correct response error in the plugin init error message ([#3388](https://github.com/argoproj/argo-rollouts/issues/3388))
* append weighted destination only when weight is mentioned ([#2734](https://github.com/argoproj/argo-rollouts/issues/2734))
* stuck rollout when 2nd deployment happens before 1st finishes ([#3354](https://github.com/argoproj/argo-rollouts/issues/3354))
* do not require pod readiness when switching desired service selector on abort ([#3338](https://github.com/argoproj/argo-rollouts/issues/3338))
* log rs name when update fails ([#3318](https://github.com/argoproj/argo-rollouts/issues/3318))
* keep rs inormer updated upon updating labels and annotations ([#3321](https://github.com/argoproj/argo-rollouts/issues/3321))
* updates to replicas and pod template at the same time causes rollout to get stuck ([#3272](https://github.com/argoproj/argo-rollouts/issues/3272))
* canary step analysis run wasn't terminated as keep running after promote action being called. Fixes [#3220](https://github.com/argoproj/argo-rollouts/issues/3220) ([#3221](https://github.com/argoproj/argo-rollouts/issues/3221))
* make sure we use the updated rs when we write back to informer ([#3237](https://github.com/argoproj/argo-rollouts/issues/3237))
* conflict on updates to replicaset revision ([#3216](https://github.com/argoproj/argo-rollouts/issues/3216))
* rollouts getting stuck due to bad rs informer updates ([#3200](https://github.com/argoproj/argo-rollouts/issues/3200))
* missing notification on error ([#3076](https://github.com/argoproj/argo-rollouts/issues/3076))
* sync notification controller configmaps/secrets first ([#3075](https://github.com/argoproj/argo-rollouts/issues/3075))
* **controller:** don't timeout rollout when still waiting for scale down delay ([#3417](https://github.com/argoproj/argo-rollouts/issues/3417))
* **controller:** treat spec.canary.analysis.template empty list as spec.canary.analysis not set ([#3446](https://github.com/argoproj/argo-rollouts/issues/3446))
* **controller:** prevent negative vsvc weights on a replica scaledown following a canary abort for istio trafficrouting ([#3467](https://github.com/argoproj/argo-rollouts/issues/3467))
* **controller:** rollback should skip all steps to active rs within RollbackWindow ([#2953](https://github.com/argoproj/argo-rollouts/issues/2953))
* **metricprovider:** support Datadog v2 API Fixes [#2813](https://github.com/argoproj/argo-rollouts/issues/2813) ([#2997](https://github.com/argoproj/argo-rollouts/issues/2997))
### Refactor
* rename interface{} => any ([#3000](https://github.com/argoproj/argo-rollouts/issues/3000))
### Test
* add unit tests for maxSurge=0, replicas=1 ([#3375](https://github.com/argoproj/argo-rollouts/issues/3375))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.20.2 to 1.21.0 ([#2950](https://github.com/argoproj/argo-rollouts/issues/2950))
* **deps:** bump github.com/antonmedv/expr from 1.12.7 to 1.13.0 ([#2951](https://github.com/argoproj/argo-rollouts/issues/2951))
### Docs
* update supported k8s version ([#2949](https://github.com/argoproj/argo-rollouts/issues/2949))
### Fix
* analysis step should be ignored after promote ([#3016](https://github.com/argoproj/argo-rollouts/issues/3016))
* **controller:** rollback should skip all steps to active rs within RollbackWindow ([#2953](https://github.com/argoproj/argo-rollouts/issues/2953))
* quote golang version string to not use go 1.2.2 ([#2915](https://github.com/argoproj/argo-rollouts/issues/2915))
* bump gotestsum and fix flakey test causing nil channel send ([#2934](https://github.com/argoproj/argo-rollouts/issues/2934))
* Update test and related docs for plugin name standard ([#2728](https://github.com/argoproj/argo-rollouts/issues/2728))
* bump k8s deps to v0.25.8 ([#2712](https://github.com/argoproj/argo-rollouts/issues/2712))
* add zachaller as lead in owers file ([#2759](https://github.com/argoproj/argo-rollouts/issues/2759))
* add unit test ([#2798](https://github.com/argoproj/argo-rollouts/issues/2798))
* add make help cmd ([#2854](https://github.com/argoproj/argo-rollouts/issues/2854))
* Add tests for pause functionality in rollout package ([#2772](https://github.com/argoproj/argo-rollouts/issues/2772))
* bump golang to 1.20 ([#2910](https://github.com/argoproj/argo-rollouts/issues/2910))
* **deps:** bump actions/setup-go from 4.0.1 to 4.1.0 ([#2947](https://github.com/argoproj/argo-rollouts/issues/2947))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.30 to 1.18.31 ([#2924](https://github.com/argoproj/argo-rollouts/issues/2924))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.29 to 1.18.30 ([#2919](https://github.com/argoproj/argo-rollouts/issues/2919))
* **deps:** bump github.com/aws/aws-sdk-go-v2 from 1.19.0 to 1.19.1 ([#2920](https://github.com/argoproj/argo-rollouts/issues/2920))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.26.3 to 1.27.0 ([#2922](https://github.com/argoproj/argo-rollouts/issues/2922))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.31 to 1.18.32 ([#2928](https://github.com/argoproj/argo-rollouts/issues/2928))
* **deps:** bump google.golang.org/grpc from 1.56.2 to 1.57.0 ([#2908](https://github.com/argoproj/argo-rollouts/issues/2908))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.28 to 1.18.29 ([#2907](https://github.com/argoproj/argo-rollouts/issues/2907))
* **deps:** bump github.com/antonmedv/expr from 1.12.6 to 1.12.7 ([#2894](https://github.com/argoproj/argo-rollouts/issues/2894))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.26.2 to 1.26.3 ([#2884](https://github.com/argoproj/argo-rollouts/issues/2884))
* **deps:** bump docker/setup-qemu-action from 2.1.0 to 2.2.0 ([#2878](https://github.com/argoproj/argo-rollouts/issues/2878))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.27 to 1.18.28 ([#2883](https://github.com/argoproj/argo-rollouts/issues/2883))
* **deps:** bump slsa-framework/slsa-github-generator from 1.6.0 to 1.7.0 ([#2880](https://github.com/argoproj/argo-rollouts/issues/2880))
* **deps:** bump actions/setup-go from 4.0.0 to 4.0.1 ([#2881](https://github.com/argoproj/argo-rollouts/issues/2881))
* **deps:** bump docker/setup-buildx-action from 2.5.0 to 2.9.1 ([#2879](https://github.com/argoproj/argo-rollouts/issues/2879))
* **deps:** bump docker/login-action from 2.1.0 to 2.2.0 ([#2877](https://github.com/argoproj/argo-rollouts/issues/2877))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.19.13 to 1.19.14 ([#2886](https://github.com/argoproj/argo-rollouts/issues/2886))
* **deps:** bump github.com/antonmedv/expr from 1.12.5 to 1.12.6 ([#2882](https://github.com/argoproj/argo-rollouts/issues/2882))
* **deps:** bump google.golang.org/grpc from 1.56.1 to 1.56.2 ([#2872](https://github.com/argoproj/argo-rollouts/issues/2872))
* **deps:** bump sigstore/cosign-installer from 3.1.0 to 3.1.1 ([#2860](https://github.com/argoproj/argo-rollouts/issues/2860))
* **deps:** bump google.golang.org/protobuf from 1.30.0 to 1.31.0 ([#2859](https://github.com/argoproj/argo-rollouts/issues/2859))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.27.0 to 1.27.1 ([#2927](https://github.com/argoproj/argo-rollouts/issues/2927))
* **deps:** bump google.golang.org/grpc from 1.55.0 to 1.56.1 ([#2856](https://github.com/argoproj/argo-rollouts/issues/2856))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.19.14 to 1.20.1 ([#2926](https://github.com/argoproj/argo-rollouts/issues/2926))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.19.12 to 1.19.13 ([#2847](https://github.com/argoproj/argo-rollouts/issues/2847))
* **deps:** bump actions/setup-go from 3.5.0 to 4.0.1 ([#2849](https://github.com/argoproj/argo-rollouts/issues/2849))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.26 to 1.18.27 ([#2844](https://github.com/argoproj/argo-rollouts/issues/2844))
* **deps:** bump github.com/prometheus/client_golang from 1.15.1 to 1.16.0 ([#2846](https://github.com/argoproj/argo-rollouts/issues/2846))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.26.1 to 1.26.2 ([#2848](https://github.com/argoproj/argo-rollouts/issues/2848))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.19.11 to 1.19.12 ([#2839](https://github.com/argoproj/argo-rollouts/issues/2839))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.26.0 to 1.26.1 ([#2840](https://github.com/argoproj/argo-rollouts/issues/2840))
* **deps:** bump sigstore/cosign-installer from 3.0.5 to 3.1.0 ([#2858](https://github.com/argoproj/argo-rollouts/issues/2858))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.25 to 1.18.26 ([#2841](https://github.com/argoproj/argo-rollouts/issues/2841))
* **deps:** bump docker/build-push-action from 4.0.0 to 4.1.0 ([#2832](https://github.com/argoproj/argo-rollouts/issues/2832))
* **deps:** bump github.com/sirupsen/logrus from 1.9.2 to 1.9.3 ([#2821](https://github.com/argoproj/argo-rollouts/issues/2821))
* **deps:** bump github.com/hashicorp/go-plugin from 1.4.9 to 1.4.10 ([#2822](https://github.com/argoproj/argo-rollouts/issues/2822))
* **deps:** bump github.com/stretchr/testify from 1.8.3 to 1.8.4 ([#2817](https://github.com/argoproj/argo-rollouts/issues/2817))
* **deps:** bump github.com/sirupsen/logrus from 1.9.1 to 1.9.2 ([#2789](https://github.com/argoproj/argo-rollouts/issues/2789))
* **deps:** bump github.com/stretchr/testify from 1.8.2 to 1.8.3 ([#2796](https://github.com/argoproj/argo-rollouts/issues/2796))
* **deps:** bump slsa-framework/slsa-github-generator from 1.7.0 to 1.8.0 ([#2936](https://github.com/argoproj/argo-rollouts/issues/2936))
* **deps:** bump sigstore/cosign-installer from 3.0.3 to 3.0.5 ([#2788](https://github.com/argoproj/argo-rollouts/issues/2788))
* **deps:** bump docker/build-push-action from 4.1.0 to 4.1.1 ([#2837](https://github.com/argoproj/argo-rollouts/issues/2837))
* **deps:** bump github.com/sirupsen/logrus from 1.9.0 to 1.9.1 ([#2784](https://github.com/argoproj/argo-rollouts/issues/2784))
* **deps:** bump codecov/codecov-action from 3.1.3 to 3.1.4 ([#2782](https://github.com/argoproj/argo-rollouts/issues/2782))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.24 to 1.18.25 ([#2770](https://github.com/argoproj/argo-rollouts/issues/2770))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.23 to 1.18.24 ([#2768](https://github.com/argoproj/argo-rollouts/issues/2768))
* **deps:** bump google.golang.org/grpc from 1.54.0 to 1.55.0 ([#2763](https://github.com/argoproj/argo-rollouts/issues/2763))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.22 to 1.18.23 ([#2756](https://github.com/argoproj/argo-rollouts/issues/2756))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.20.1 to 1.20.2 ([#2941](https://github.com/argoproj/argo-rollouts/issues/2941))
* **deps:** replace `github.com/ghodss/yaml` with `sigs.k8s.io/yaml` ([#2681](https://github.com/argoproj/argo-rollouts/issues/2681))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.25.10 to 1.26.0 ([#2755](https://github.com/argoproj/argo-rollouts/issues/2755))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.19.10 to 1.19.11 ([#2757](https://github.com/argoproj/argo-rollouts/issues/2757))
* **deps:** bump github.com/prometheus/client_golang from 1.15.0 to 1.15.1 ([#2754](https://github.com/argoproj/argo-rollouts/issues/2754))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.21 to 1.18.22 ([#2746](https://github.com/argoproj/argo-rollouts/issues/2746))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.25.9 to 1.25.10 ([#2745](https://github.com/argoproj/argo-rollouts/issues/2745))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.27.1 to 1.27.2 ([#2944](https://github.com/argoproj/argo-rollouts/issues/2944))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.19.9 to 1.19.10 ([#2747](https://github.com/argoproj/argo-rollouts/issues/2747))
* **deps:** bump codecov/codecov-action from 3.1.2 to 3.1.3 ([#2735](https://github.com/argoproj/argo-rollouts/issues/2735))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.32 to 1.18.33 ([#2943](https://github.com/argoproj/argo-rollouts/issues/2943))
* **deps:** bump github.com/prometheus/client_golang from 1.14.0 to 1.15.0 ([#2721](https://github.com/argoproj/argo-rollouts/issues/2721))
* **deps:** bump codecov/codecov-action from 3.1.1 to 3.1.2 ([#2711](https://github.com/argoproj/argo-rollouts/issues/2711))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.20 to 1.18.21 ([#2709](https://github.com/argoproj/argo-rollouts/issues/2709))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.19.8 to 1.19.9 ([#2708](https://github.com/argoproj/argo-rollouts/issues/2708))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.25.8 to 1.25.9 ([#2710](https://github.com/argoproj/argo-rollouts/issues/2710))
* **deps:** bump github.com/aws/aws-sdk-go-v2/config from 1.18.19 to 1.18.20 ([#2705](https://github.com/argoproj/argo-rollouts/issues/2705))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/elasticloadbalancingv2 from 1.19.7 to 1.19.8 ([#2704](https://github.com/argoproj/argo-rollouts/issues/2704))
* **deps:** bump github.com/aws/aws-sdk-go-v2 from 1.17.7 to 1.17.8 ([#2703](https://github.com/argoproj/argo-rollouts/issues/2703))
* **deps:** bump github.com/aws/aws-sdk-go-v2/service/cloudwatch from 1.25.7 to 1.25.8 ([#2702](https://github.com/argoproj/argo-rollouts/issues/2702))
* **deps:** bump peter-evans/create-pull-request from 4 to 5 ([#2697](https://github.com/argoproj/argo-rollouts/issues/2697))
* **deps:** bump github.com/spf13/cobra from 1.6.1 to 1.7.0 ([#2698](https://github.com/argoproj/argo-rollouts/issues/2698))
* **deps:** bump github.com/influxdata/influxdb-client-go/v2 from 2.12.2 to 2.12.3 ([#2684](https://github.com/argoproj/argo-rollouts/issues/2684))
### Ci
* generate attestations during a release ([#2785](https://github.com/argoproj/argo-rollouts/issues/2785))
* use keyless signing for main and release branches ([#2783](https://github.com/argoproj/argo-rollouts/issues/2783))
### Docs
* mirroring support in Traefik is not implemented yet ([#2904](https://github.com/argoproj/argo-rollouts/issues/2904))
* update contributions.md to include k3d as recommended cluster, add details on e2e test setup, and update kubectl install link. Fixes [#1750](https://github.com/argoproj/argo-rollouts/issues/1750) ([#1867](https://github.com/argoproj/argo-rollouts/issues/1867))
* fix minor mistakes in Migrating to Deployments ([#2270](https://github.com/argoproj/argo-rollouts/issues/2270))
* Update docs of Rollout spec to add active/previewMetadata ([#2833](https://github.com/argoproj/argo-rollouts/issues/2833))
* Support Multiple ALB Ingresses ([#2639](https://github.com/argoproj/argo-rollouts/issues/2639))
* add merge key to analysis template ([#2842](https://github.com/argoproj/argo-rollouts/issues/2842))
* retain TLS configuration for canary ingresses in the nginx integration. Fixes [#1134](https://github.com/argoproj/argo-rollouts/issues/1134) ([#2679](https://github.com/argoproj/argo-rollouts/issues/2679))
* **analysis:** Adds rollout Spec.Selector.MatchLabels to AnalysisRun. Fixes [#2888](https://github.com/argoproj/argo-rollouts/issues/2888) ([#2903](https://github.com/argoproj/argo-rollouts/issues/2903))
* **controller:** Add custom metadata support for AnalysisRun. Fixes [#2740](https://github.com/argoproj/argo-rollouts/issues/2740) ([#2743](https://github.com/argoproj/argo-rollouts/issues/2743))
* rollout not modify the VirtualService whit setHeaderRoute step with workloadRef ([#2797](https://github.com/argoproj/argo-rollouts/issues/2797))
* get new httpRoutesI after removeRoute() to avoid duplicates. Fixes [#2769](https://github.com/argoproj/argo-rollouts/issues/2769) ([#2887](https://github.com/argoproj/argo-rollouts/issues/2887))
* change logic of analysis run to better handle errors ([#2695](https://github.com/argoproj/argo-rollouts/issues/2695))
* istio dropping fields during removing of managed routes ([#2692](https://github.com/argoproj/argo-rollouts/issues/2692))
* resolve args to metric in garbage collection function ([#2843](https://github.com/argoproj/argo-rollouts/issues/2843))
* properly wrap Datadog API v2 request body ([#2771](https://github.com/argoproj/argo-rollouts/issues/2771)) ([#2775](https://github.com/argoproj/argo-rollouts/issues/2775))
* **analysis:** Graphite metric provider - index out of range [0] with length 0 ([#2751](https://github.com/argoproj/argo-rollouts/issues/2751))
* **controller:** Remove name label from some k8s client metrics on events and replicasets ([#2851](https://github.com/argoproj/argo-rollouts/issues/2851))
* **controller:** Fix for rollouts getting stuck in loop ([#2689](https://github.com/argoproj/argo-rollouts/issues/2689))
* **trafficrouting:** apply stable selectors on canary service on rollout abort [#2781](https://github.com/argoproj/argo-rollouts/issues/2781) ([#2818](https://github.com/argoproj/argo-rollouts/issues/2818))
The metric labels have changed on controller_clientset_k8s_request_total to not include the name of the resource for events and replicasets. These names have generated hashes in them and cause really high cardinality.
Remove name label from k8s some client metrics
The `name` label in the `controller_clientset_k8s_request_total` metric
produce an excessive amount of cardinality for `events` and `replicasets`.
This can lead to hundreds of thousands of unique metrics over a couple
weeks in a large deployment. Set the name to "N/A" for these client request
To learn more about Argo Rollouts go to the [complete documentation](https://argo-rollouts.readthedocs.io/en/stable/).
@ -96,3 +101,6 @@ You can reach the Argo Rollouts community and developers via the following chann
* [How Scalable is Argo-Rollouts: A Cloud Operator’s Perspective](https://www.youtube.com/watch?v=rCEhxJ2NSTI)
* [Minimize Impact in Kubernetes Using Argo Rollouts](https://medium.com/@arielsimhon/minimize-impact-in-kubernetes-using-argo-rollouts-992fb9519969)
* [Progressive Application Delivery with GitOps on Red Hat OpenShift](https://www.youtube.com/watch?v=DfeL7cdTx4c)
* [Progressive delivery for Kubernetes Config Maps using Argo Rollouts](https://codefresh.io/blog/progressive-delivery-for-kubernetes-config-maps-using-argo-rollouts/)
* [Multi-Service Progressive Delivery with Argo Rollouts](https://codefresh.io/blog/multi-service-progressive-delivery-with-argo-rollouts/)
* [Progressive Delivery for Stateful Services Using Argo Rollouts](https://codefresh.io/blog/progressive-delivery-for-stateful-services-using-argo-rollouts/)
// failureLimit was checked above and not reached.
// consecutiveSuccessLimit was checked above and not reached.
failureLimit:="0"
ifmetric.FailureLimit!=nil{
failureLimit=metric.FailureLimit.String()
}
logger.Infof("Metric Assessment Result - %s: ConsecutiveSuccessLimit (%s) Not Reached and FailureLimit (%s) Not Violated",v1alpha1.AnalysisPhaseInconclusive,metric.ConsecutiveSuccessLimit.String(),failureLimit)
returnv1alpha1.AnalysisPhaseInconclusive
}elseifsuccessApplicable{
logger.Infof("Metric Assessment Result - %s: ConsecutiveSuccessLimit (%s) Not Reached",v1alpha1.AnalysisPhaseFailed,metric.ConsecutiveSuccessLimit.String())
returnv1alpha1.AnalysisPhaseFailed
}elseiffailureApplicable{
// failureLimit was not reached in assessMetricFailureInconclusiveOrError above.
// AnalysisPhaseSuccessful below.
}else{
// This cannot happen, since one of failureLimit or consecutiveSuccessLimit will be applicable
// We validate that failureLimit >= 0 when consecutiveSuccessLimit == 0
}
logger.Infof("Metric Assessment Result - %s: Count (%s) Reached",v1alpha1.AnalysisPhaseSuccessful,effectiveCount.String())
returnv1alpha1.AnalysisPhaseSuccessful
}
@ -613,7 +663,8 @@ func assessMetricFailureInconclusiveOrError(metric v1alpha1.Metric, result v1alp
command.Flags().IntVar(&analysisThreads,"analysis-threads",controller.DefaultAnalysisThreads,"Set the number of worker threads for the Experiment controller")
command.Flags().IntVar(&serviceThreads,"service-threads",controller.DefaultServiceThreads,"Set the number of worker threads for the Service controller")
command.Flags().IntVar(&ingressThreads,"ingress-threads",controller.DefaultIngressThreads,"Set the number of worker threads for the Ingress controller")
command.Flags().IntVar(&ephemeralMetadataThreads,"ephemeral-metadata-threads",rollout.DefaultEphemeralMetadataThreads,"Set the number of worker threads for the Ephemeral Metadata reconciler")
command.Flags().StringVar(&targetGroupBindingVersion,"aws-target-group-binding-api-version",defaults.DefaultTargetGroupBindingAPIVersion,"Set the default AWS TargetGroupBinding apiVersion that controller uses when verifying target group weights.")
command.Flags().StringVar(&albTagKeyResourceID,"alb-tag-key-resource-id",defaults.DefaultAlbTagKeyResourceID,"Set the default AWS LoadBalancer tag key for resource ID that controller uses when verifying target group weights.")
command.Flags().StringVar(&istioVersion,"istio-api-version",defaults.DefaultIstioVersion,"Set the default Istio apiVersion that controller should look when manipulating VirtualServices.")
command.Flags().StringVar(&ambassadorVersion,"ambassador-api-version",defaults.DefaultAmbassadorVersion,"Set the Ambassador apiVersion that controller should look when manipulating Ambassador Mappings.")
command.Flags().StringVar(&trafficSplitVersion,"traffic-split-api-version",defaults.DefaultSMITrafficSplitVersion,"Set the default TrafficSplit apiVersion that controller uses when creating TrafficSplits.")
command.Flags().StringVar(&traefikAPIGroup,"traefik-api-group",defaults.DefaultTraefikAPIGroup,"Set the default Traefik apiGroup that controller uses.")
command.Flags().StringVar(&traefikVersion,"traefik-api-version",defaults.DefaultTraefikVersion,"Set the default Traefik apiVersion that controller uses.")
command.Flags().StringVar(&ingressVersion,"ingress-api-version","","Set the Ingress apiVersion that the controller should use.")
command.Flags().StringVar(&appmeshCRDVersion,"appmesh-crd-version",defaults.DefaultAppMeshCRDVersion,"Set the default AppMesh CRD Version that controller uses when manipulating resources.")
command.Flags().StringArrayVar(&albIngressClasses,"alb-ingress-classes",defaultALBIngressClass,"Defines all the ingress class annotations that the alb ingress controller operates on. Defaults to alb")
command.Flags().DurationVar(&electOpts.LeaderElectionRenewDeadline,"leader-election-renew-deadline",controller.DefaultLeaderElectionRenewDeadline,"The interval between attempts by the acting master to renew a leadership slot before it stops leading. This must be less than or equal to the lease duration. This is only applicable if leader election is enabled.")
command.Flags().DurationVar(&electOpts.LeaderElectionRetryPeriod,"leader-election-retry-period",controller.DefaultLeaderElectionRetryPeriod,"The duration the clients should wait between attempting acquisition and renewal of a leadership. This is only applicable if leader election is enabled.")
command.Flags().BoolVar(&selfServiceNotificationEnabled,"self-service-notification-enabled",false,"Allows rollouts controller to pull notification config from the namespace that the rollout resource is in. This is useful for self-service notification.")
command.Flags().StringSliceVar(&controllersEnabled,"controllers",nil,"Explicitly specify the list of controllers to run, currently only supports 'analysis', eg. --controller=analysis. Default: all controllers are enabled")
command.Flags().StringVar(&pprofAddress,"enable-pprof-address","","Enable pprof profiling on controller by providing a server address.")
Kustomize is required for unit tests (`make test` is using it), so you [must install it](https://kubectl.docs.kubernetes.io/installation/kustomize/)
locally if you wish to make code contributions to Argo Rollouts.
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
-`golangci-lint` to lint the project.
-`protoc` and `swagger-codegen` to generate proto related files
-`yarn` to build the UI
Run the following commands to install them:
@ -56,10 +59,9 @@ cd ~/go/src/github.com/argoproj/argo-rollouts
The `make controller` command will build the controller.
* `make install-tools-local` - Runs scripts to install codegen utility CLIs necessary for codegen.
* `make codegen` - Runs the code generator that creates the informers, client, lister, and deepcopies from the types.go and modifies the open-api spec.
- `make install-tools-local` - Runs scripts to install codegen utility CLIs necessary for codegen.
- `make codegen` - Runs the code generator that creates the informers, client, lister, and deepcopies from the types.go and modifies the open-api spec.
## Running Controller Locally
@ -83,11 +85,7 @@ make test
## Running E2E tests
The end-to-end tests need to run against a kubernetes cluster with the Argo Rollouts controller
running. The rollout controller can be started with the command:
```
make start-e2e
```
running.
Start and prepare your cluster for e2e tests:
@ -98,6 +96,12 @@ kubectl apply -k manifests/crds
kubectl apply -f test/e2e/crds
```
The rollout controller can be started with the command:
```
make start-e2e
```
Then run the e2e tests:
```
@ -110,6 +114,66 @@ To run a subset of e2e tests, you need to specify the suite with `-run`, and the
E2E_TEST_OPTIONS="-run 'TestCanarySuite' -testify.m 'TestCanaryScaleDownOnAbortNoTrafficRouting'" make test-e2e
```
Available test suites [are the following](https://github.com/argoproj/argo-rollouts/tree/master/test/e2e):
* `TestBlueGreenSuite`
* `TestCanarySuite`
* `TestAnalysisSuite`
* `TestExperimentSuite`
* `TestFunctionalSuite`
* `TestRollbackSuite`
* `TestIstioSuite`
* `TestHeaderRoutingSuite` (Istio only)
* `TestMirrorRouteSuite` (Istio only)
* `TestAPISIXSuite`
* `TestAppMeshSuite`
* `TestAWSSuite`
* `StepPluginSuite`
* `SMISuite` (SMI is [deprecated](https://www.cncf.io/blog/2023/10/03/cncf-archives-the-service-mesh-interface-smi-project/))
* `SMIIngressSuite` (SMI is [deprecated](https://www.cncf.io/blog/2023/10/03/cncf-archives-the-service-mesh-interface-smi-project/))
## Running the UI
If you'd like to run the UI locally, you first need a running Rollouts controller. This can be a locally running controller with a k3d cluster, as described above, or a controller running in a remote Kubernetes cluster.
In order for the local React app to communicate with the controller and Kubernetes API, run the following to open a port forward to the dashboard:
```bash
kubectl argo rollouts dashboard
```
Note that you can also build the API server and run this instead,
```
make plugin
./dist/kubectl-argo-rollouts dashboard
```
In another terminal, run the following to start the UI:
```bash
cd ui
yarn install
yarn start
```
## Getting your feature accepted
To be eligible for inclusion in a minor release, a new feature must meet the following criteria before the release’s RC
date.
If it is a large feature that involves significant design decisions, that feature must be described in a Proposal.
The feature PR must include:
* Tests (passing)
* Documentation
* If necessary, a note in the Upgrading docs for the planned minor release
* The PR must be reviewed, approved, and merged by an Approver.
If these criteria are not met by the RC date, the feature will be ineligible for inclusion in the RC series or GA for
that minor release. It will have to wait for the next minor release.
## Controller architecture
Argo Rollouts is actually a collection of individual controllers
@ -119,11 +183,11 @@ that handle a specific aspect of Progressive Delivery.
@ -135,36 +199,35 @@ KUBECONFIG=~/.kube/minikube make test-e2e
```
2. To run a specific e2e test, set the `E2E_TEST_OPTIONS` environment variable to specify the test
(or test regex):
(or test regex):
```shell
make test-e2e E2E_TEST_OPTIONS="-testify.m ^TestRolloutRestart$"
```
3. The e2e tests are designed to run as quickly as possible, eliminating readiness and termination
delays. However, it is often desired to artificially slow down the tests for debugging purposes,
as well as to understand what the test is doing. To delay startup and termination of pods, set the
`E2E_POD_DELAY` to an integer value in seconds. This environment variable is often coupled with
`E2E_TEST_OPTIONS` to debug and slow down a specific test.
delays. However, it is often desired to artificially slow down the tests for debugging purposes,
as well as to understand what the test is doing. To delay startup and termination of pods, set the
`E2E_POD_DELAY` to an integer value in seconds. This environment variable is often coupled with
`E2E_TEST_OPTIONS` to debug and slow down a specific test.
```shell
make test-e2e E2E_POD_DELAY=10
```
4. Increasing the timeout. The E2E tests time out waiting on conditions to be met within 60 seconds.
If debugging the rollout controller, it may be useful to increase this timeout while say sitting
at a debugger breakpoint:
If debugging the rollout controller, it may be useful to increase this timeout while say sitting
at a debugger breakpoint:
```shell
make test-e2e E2E_WAIT_TIMEOUT=999999
```
5. The e2e tests leverage a feature of the controller allowing the controller to be sharded with
a user-specific "instance id" label. This allows the tests to operate only on rollouts with the
specified label, and prevents any other controllers (including the system rollout controller),
from also operating on the same set of rollouts. This value can be changed (from the default of
`argo-rollouts-e2e`), using the `E2E_INSTANCE_ID` environment variable:
a user-specific "instance id" label. This allows the tests to operate only on rollouts with the
specified label, and prevents any other controllers (including the system rollout controller),
from also operating on the same set of rollouts. This value can be changed (from the default of
`argo-rollouts-e2e`), using the `E2E_INSTANCE_ID` environment variable:
```shell
make start-e2e E2E_INSTANCE_ID=foo
@ -177,6 +240,11 @@ Alternatively, the e2e tests can be run against the system controller (i.e. with
make start-e2e E2E_INSTANCE_ID=''
```
6. Working on CRDs? While editing them directly works when you are finding the shape of things you want, the final CRDs are autogenerated. Make sure to regenerate them by running `make gen-crd` before submitting PRs. They are controlled by the relevant annotations in the types file:
eg: Analysis Templates are controlled by annotations in `pkg/apis/rollouts/v1alpha1/analysis_types.go`.
Refer to https://book-v1.book.kubebuilder.io/beyond_basics/generating_crd.html and https://book.kubebuilder.io/reference/markers/crd-validation.html for more info on annotations you can use.
Be sure to read the [Best practices page](../best-practices) as well.
## General
### Does Argo Rollouts depend on Argo CD or any other Argo project?
@ -13,7 +15,7 @@ Argo CD understands the health of Argo Rollouts resources via Argo CD’s [Lua h
As a result, an operator can build automation to react to the states of the Argo Rollouts resources. For example, if a Rollout created by Argo CD is paused, Argo CD detects that and marks the Application as suspended. Once the new version is verified to be good, the operator can use Argo CD’s resume resource action to unpause the Rollout so it can continue to make progress.
### Can we run the Argo Rollouts kubectl plugin commands via Argo CD?
Argo CD supports running Lua scripts to modify resource kinds (i.e. suspending a CronJob by setting the `.spec.suspend` to true). These Lua Scripts can be configured in the argocd-cm ConfigMap or upstreamed to the Argo CD's [resource_customizations](https://github.com/argoproj/argo-cd/tree/master/resource_customizations) directory. These custom actions have two Lua scripts: one to modify the said resource and another to detect if the action can be executed (i.e. A user should not be able to resuming a unpaused Rollout). Argo CD allows users to execute these actions via the UI or CLI.
Argo CD supports running Lua scripts to modify resource kinds (i.e. suspending a CronJob by setting the `.spec.suspend` to true). These Lua Scripts can be configured in the argocd-cm ConfigMap or upstreamed to the Argo CD's [resource_customizations](https://github.com/argoproj/argo-cd/tree/master/resource_customizations) directory. These custom actions have two Lua scripts: one to modify the said resource and another to detect if the action can be executed (i.e. A user should not be able to resuming an unpaused Rollout). Argo CD allows users to execute these actions via the UI or CLI.
In the CLI, a user (or a CI system) can run
```bash
@ -41,6 +43,14 @@ solution that does not follow the GitOps approach.
Yes. A k8s cluster can run multiple replicas of Argo-rollouts controllers to achieve HA. To enable this feature, run the controller with `--leader-elect` flag and increase the number of replicas in the controller's deployment manifest. The implementation is based on the [k8s client-go's leaderelection package](https://pkg.go.dev/k8s.io/client-go/tools/leaderelection#section-documentation). This implementation is tolerant to *arbitrary clock skew* among replicas. The level of tolerance to skew rate can be configured by setting `--leader-election-lease-duration` and `--leader-election-renew-deadline` appropriately. Please refer to the [package documentation](https://pkg.go.dev/k8s.io/client-go/tools/leaderelection#pkg-overview) for details.
### Can we install Argo Rollouts centrally in a cluster and manage Rollout resources in external clusters?
No you cannot do that (even though Argo CD can work that way). This is by design because the Rollout is a custom resource unknown to vanilla Kubernetes. You need the Rollout CRD as well as the controller in the deployment cluster (every cluster that will use workloads with Rollouts).
### What is the version skew policy between the controller and the kubectl plugin?
The Argo Rollout CLI/Kubectl plugin just patches the Rollout object or reads fields from it. [There is no separate "Argo Rollouts API"](../best-practices#there-is-no-argo-rollouts-api). Old versions of the plugin might not understand new fields that are added in the [Rollout specification](../features/specification/). We have never made a breaking change intentionally (removed something from the Rollout Spec). So old clients should work even with newer Rollout versions (excluding new features).
## Rollouts
### Which deployment strategies does Argo Rollouts support?
The field `apiVersion` refers to the API version of Datadog (v1 or v2). Default value is `v1` if this is omitted.
!!! note
Datadog is moving away from the legacy v1 API. Rate limits imposed by Datadog are therefore stricter when using v1. It is recommended to switch to v2 soon. If you switch to v2, you will not be able to use formulas (operations between individual queries).
The field `apiVersion` refers to the API version of Datadog (v1 or v2). Default value is `v1` if this is omitted. See "Working with Datadog API v2" below for more information.
Datadog api and app tokens can be configured in a kubernetes secret in argo-rollouts namespace.
@ -46,3 +40,204 @@ stringData:
```
`apiVersion` here is different from the `apiVersion` from the Datadog configuration above.
!!! important
###### Namespaced secret
Datadog integration supports referring to secrets inside the same namespace as argo-rollouts (by default)
or referring to a secret in the same namespace as the `AnalysisTemplate`.
To use a secret from the `AnalysisTemplate` namespace, include a `secretRef` section in the template, specifying the `name` of the secret and setting the `namespaced` property to `true`.
The process for retrieving Datadog credentials is as follows:
1. **If a `secretRef` is defined in the `AnalysisTemplate`:** Argo Rollouts will search for the secret with the specified name in the namespace where the template resides.
2. **If the secret is not found in the specified namespace:** Argo Rollouts will then check the environment variables.
3. **If the credentials are not found in environment variables:** Argo Rollouts will look for a secret named "Datadog" in the namespace where Argo Rollouts itself is deployed.
---
Let me know if there's anything else you'd like to adjust!
While some basic v2 functionality is working in earlier versions, the new properties of `formula` and `queries` are only available as of v1.7
#### Moving to v2
If your old v1 was just a simple metric query - no formula as part of the query - then you can just move to v2 by updating the `apiVersion` in your existing Analysis Template, and everything should work.
If you have a formula, you will need to update how you configure your metric. Here is a before/after example of what your Analysis Template should look like:
Datadog queries can return empty results if the query takes place during a time interval with no metrics. The Datadog provider will return a `nil` value yielding an error during the evaluation phase like:
```
invalid operation: < (mismatched types <nil> and float64)
```
However, empty query results yielding a `nil` value can be handled using the `default()` function. Here is a succeeding example using the `default()` function:
```yaml
successCondition: default(result, 0) <0.05
```
#### Metric aggregation (v2 only)
By default, Datadog analysis run is configured to use `last` metric aggregator when querying Datadog v2 API. This value can be overridden by specifying a new `aggregator` value from a list of supported aggregators (`avg,min,max,sum,last,percentile,mean,l2norm,area`) for the V2 API ([docs](https://docs.datadoghq.com/api/latest/metrics/#query-scalar-data-across-multiple-products)).
For example, using count-based distribution metric (`count:metric{*}.as_count()`) with values `1,9,3,7,5` in a given `interval` will make `last` aggregator return `5`. To return a sum of all values (`25`), set `aggregator: sum` in Datadog provider block and use `moving_rollup()` function to aggregate values in the specified rollup interval. These functions can be combined in a `formula` to perform additional calculations:
formula: "moving_rollup(a, 300, 'sum') / moving_rollup(b, 300, 'sum') * 100" # percentage of requests with errors
```
#### Templates and Helm
Helm and Argo Rollouts both try to parse things between `{{ ... }}` when rendering templates. If you use Helm to deliver your manifests, you will need to escape `{{ args.whatever }}`. Using the example above, here it is set up for Helm:
Argo Rollouts allows you some control over where your metric job runs.
The following env vars can be set on the Rollouts controller:
`ARGO_ROLLOUTS_ANALYSIS_JOB_NAMESPACE` will allow you to run your metric jobs in a namespace other than the default (which can vary depending on if you are running Rollouts in cluster mode or not).
`ARGO_ROLLOUTS_ANALYSIS_JOB_KUBECONFIG` will allow running metric jobs in a different cluster entirely. This should be a path to the kubeconfig you want to use.
profile: my-newrelic-secret # optional, defaults to 'newrelic'
query: |
FROM Transaction SELECT percentage(count(*), WHERE httpResponseCode != 500) as successRate where appName = '{{ args.application-name }}'
timeout: 10 # NRQL query timeout in seconds. Optional, defaults to 5
```
The `result` evaluated for the condition will always be map or list of maps. The name will follow the pattern of either `function` or `function.field`, e.g. `SELECT average(duration) from Transaction` will yield `average.duration`. In this case the field result cannot be accessed with dot notation and instead should be accessed like `result['average.duration']`. Query results can be renamed using the [NRQL clause `AS`](https://docs.newrelic.com/docs/query-your-data/nrql-new-relic-query-language/get-started/nrql-syntax-clauses-functions#sel-as) as seen above.
@ -54,3 +55,11 @@ stringData:
base-url-rest: <your-base-url>
base-url-nerdgraph: <your-base-url>
```
## Additional Metadata
The New Relic provider returns the below metadata under the `Metadata` map in the `MetricsResult` object of `AnalysisRun`.
| KEY | Description |
|-----------------------|-------------|
| ResolvedNewRelicQuery | Resolved query after substituting the template's arguments |
There are two methods of installing and using an argo rollouts plugin. The first method is to mount up the plugin executable
into the rollouts controller container. The second method is to use a HTTP(S) server to host the plugin executable.
into the rollouts controller container. The second method is to use an HTTP(S) server to host the plugin executable.
### Mounting the plugin executable into the rollouts controller container
There are a few ways to mount the plugin executable into the rollouts controller container. Some of these will depend on your
particular infrastructure. Here are a few methods:
* Using an init container to download the plugin executable
* Using a Kubernetes volume mount with a shared volume such as NFS, EBS, etc.
* Building the plugin into the rollouts controller container
- Using an init container to download the plugin executable
- Using a Kubernetes volume mount with a shared volume such as NFS, EBS, etc.
- Building the plugin into the rollouts controller container
Then you can use the configmap to point to the plugin executable file location. Example:
@ -31,13 +33,26 @@ metadata:
name: argo-rollouts-config
data:
metricProviderPlugins: |-
- name: "argoproj-labs/sample-prometheus" # name of the plugin, it must match the name required by the plugin so it can find it's configuration
- name: "argoproj-labs/sample-prometheus" # name of the plugin, it must match the name required by the plugin so it can find its configuration
location: "file://./my-custom-plugin" # supports http(s):// urls and file://
```
### Using a HTTP(S) server to host the plugin executable
### Using an HTTP(S) server to host the plugin executable
Argo Rollouts supports downloading the plugin executable from a HTTP(S) server. To use this method, you will need to
!!! warning "Installing a plugin with http(s)"
Depending on which method you use to install and the plugin, there are some things to be aware of.
The rollouts controller will not start if it can not download or find the plugin executable. This means that if you are using
a method of installation that requires a download of the plugin and the server hosting the plugin for some reason is not available and the rollouts
controllers pod got deleted while the server was down or is coming up for the first time, it will not be able to start until
the server hosting the plugin is available again.
Argo Rollouts will download the plugin at startup only once but if the pod is deleted it will need to download the plugin again on next startup. Running
Argo Rollouts in HA mode can help a little with this situation because each pod will download the plugin at startup. So if a single pod gets
deleted during a server outage, the other pods will still be able to take over because there will already be a plugin executable available to it. It is the
responsibility of the Argo Rollouts administrator to define the plugin installation method considering the risks of each approach.
Argo Rollouts supports downloading the plugin executable from an HTTP(S) server. To use this method, you will need to
configure the controller via the `argo-rollouts-config` configmap and set `pluginLocation` to a http(s) url. Example:
```yaml
@ -47,11 +62,24 @@ metadata:
name: argo-rollouts-config
data:
metricProviderPlugins: |-
- name: "argoproj-labs/sample-prometheus" # name of the plugin, it must match the name required by the plugin so it can find it's configuration
- name: "argoproj-labs/sample-prometheus" # name of the plugin, it must match the name required by the plugin so it can find its configuration
location: "https://github.com/argoproj-labs/rollouts-plugin-metric-sample-prometheus/releases/download/v0.0.4/metric-plugin-linux-amd64" # supports http(s):// urls and file://
sha256: "dac10cbf57633c9832a17f8c27d2ca34aa97dd3d" #optional sha256 checksum of the plugin executable
headersFrom: #optional headers for the download via http request
- secretRef:
name: secret-name
---
apiVersion: v1
kind: Secret
metadata:
name: secret-name
stringData:
Authorization: Basic <Base64TOKEN>
My-Header: value
```
## Some words of caution
Depending on which method you use to install and the plugin, there are some things to be aware of.
@ -67,8 +95,13 @@ responsibility of the Argo Rollouts administrator to define the plugin installat
## List of Available Plugins (alphabetical order)
#### Add Your Plugin Here
* If you have created a plugin, please submit a PR to add it to this list.
- The application is an OpenSearch plugin designed for use with the Argo Rollouts plugin system. This plugin enables the integration of OpenSearch metrics into Argo Rollouts, allowing for advanced metric analysis and monitoring during application rollouts.
### Range query and successCondition/failureCondition
Since range queries will usually return multiple values from prometheus. It is important to assert on every value returned. See the following examples:
* ❌ `result[0] < 1000` - this will only check the first value returned
* ✅ `all(result, # < 1000)` - checks every value returns from prometheus
See [expr](https://github.com/expr-lang/expr) for more expression options.
## Authorization
### Utilizing Amazon Managed Prometheus
Amazon Managed Prometheus can be used as the prometheus data source for analysis. In order to do this the namespace where your analysis is running will have to have the appropriate [IRSA attached](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-onboard-ingest-metrics-new-Prometheus.html#AMP-onboard-new-Prometheus-IRSA) to allow for prometheus queries. Once you ensure the proper permissions are in place to access AMP, you can use an AMP workspace url in your ```provider``` block and add a SigV4 config for Sigv4 signing:
@ -61,6 +104,55 @@ provider:
roleArn: $ROLEARN
```
### With OAuth2
You can setup an [OAuth2 client credential](https://datatracker.ietf.org/doc/html/rfc6749#section-4.4) flow using the following values:
```yaml
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
name: success-rate
spec:
args:
- name: service-name
# from secret
- name: oauthSecret # This is the OAuth2 shared secret
valueFrom:
secretKeyRef:
name: oauth-secret
key: secret
metrics:
- name: success-rate
interval: 5m
# NOTE: prometheus queries return results in the form of a vector.
# So it is common to access the index 0 of the returned array to obtain the value
The AnalysisRun will first get an access token using that information, and provide it as an `Authorization: Bearer` header for the metric provider call.
## Additional Metadata
Any additional metadata from the Prometheus controller, like the resolved queries after substituting the template's
- key: Content-Type # if body is a json, it is recommended to set the Content-Type
value: "application/json"
jsonPath: "{$.data.ok}"
```
In that case, no need to provide specifically the `Authentication` header.
The AnalysisRun will first get an access token using that information, and provide it as an `Authorization: Bearer` header for the metric provider call.
document.querySelector("div[data-md-component=announce]").innerHTML="<div id='announce-msg'>You are viewing the docs for an unreleased version of Argo Rollouts, <a href='https://argoproj.github.io/argo-rollouts/'>click here to go to the latest stable version.</a></div>";
document.querySelector("div[data-md-component=announce]").innerHTML="<div id='announce-msg'>You are viewing the docs for a previous version of Argo Rollouts, <a href='https://argoproj.github.io/argo-rollouts/'>click here to go to the latest stable version.</a></div>";
This document describes some best practices, tips and tricks when using Argo Rollouts.
This document describes some best practices, tips and tricks when using Argo Rollouts. Be sure to read the [FAQ page](../FAQ) as well.
## Check application compatibility
Argo Rollouts is a great solution for applications that your team is deploying in a continuous manner (and you have access to the source code). Before using Argo Rollouts you need to contact the developers of the application and verify that you can indeed run multiple versions of the same application at the same time.
Not all applications can work with Argo Rollouts. Applications that use shared resources (e.g. writing to a shared file) will have issues, and "worker" type applications (that load data from queues) will rarely work ok without source code modifications.
Note that using Argo Rollouts for "infrastructure" applications such as cert-manager, nginx, coredns, sealed-secrets etc is **NOT** recommended.
## Understand the scope of Argo Rollouts
Currently, Argo Rollouts works with a single Kubernetes deployment/application and within a single cluster only. You also need to have the controller deployed on *every* cluster where a Rollout is running if have more than one clusters using Rollout workloads.
If you want to look at multiple-services on multiple clusters
see discussion at issues [2737](https://github.com/argoproj/argo-rollouts/issues/2737), [451](https://github.com/argoproj/argo-rollouts/issues/451) and [2088](https://github.com/argoproj/argo-rollouts/issues/2088).
Note also that Argo Rollouts is a self-contained solution. It doesn't need Argo CD or any other Argo project to work.
## Understand your use case
Argo Rollouts is perfect for all progressive delivery scenarios as explained in [the concepts page](../concepts).
You should *NOT* use Argo Rollouts for preview/ephemeral environments. For that use case check the [Argo CD Pull Request generator](https://argo-cd.readthedocs.io/en/stable/operator-manual/applicationset/Generators-Pull-Request/).
The recommended way to use Argo Rollouts is for brief deployments that take 15-20 minutes or maximum 1-2 hours. If you want to run new versions for days or weeks before deciding to promote, then Argo Rollouts is probably not the best solution for you.
Keeping parallel releases for long times, complicates the deployment process a lot and opens several questions where different people have different views on how Argo Rollouts should work.
For example let's say that you are testing for a week version 1.3 as stable and 1.4 as preview.
Then somebody deploys 1.5
1. Some people believe that the new state should be 1.3 stable and 1.5 as preview
1. Some people believe that the new state should be 1.4 stable and 1.5 as preview
Currently, Argo Rollouts follows the first approach, under the assumption that something was really wrong with 1.4 and 1.5 is the hotfix.
And then let's say that 1.5 has an issue. Some people believe that Argo rollouts should "rollback" to 1.3 while other people think it should rollback to 1.4
Currently, Argo Rollouts assumes that the version to rollback is always 1.3 regardless of how many "hotfixes" have been previewed in-between.
All these problems are not present if you make the assumption that each release stays active only for a minimal time and you always create one new version when the previous one has finished.
Also, if you want to run a wave of multiple versions at the same time (i.e. have 1.1 and 1.2 and 1.3 running at the same time), know that Argo Rollouts was not designed for this scenario. Argo Rollouts always works with the assumption that there is one stable/previous version and one preview/next version.
A version that has just been promoted is assumed to be ready for production and has already passed all your tests (either manual or automated).
## Prepare your metrics
The end-goal for using Argo Rollouts is to have **fully automated** deployments that also include rollbacks when needed.
While Argo Rollouts supports manual promotions and other manual pauses, these are best used for experimentation and test reasons.
Ideally you should have proper metrics that tell you in 5-15 minutes if a deployment is successful or not. If you don't have those metrics, then you will miss a lot of value from Argo Rollouts.
If you are doing a deployment right now and then have an actual human looking at logs/metrics/traces for the next 2 hours, adopting Argo Rollouts is not going to help you a lot with automated deployments.
Get your [metrics](../features/analysis) in place first and test them with dry-runs before applying them to production deployments.
## There is no "Argo Rollouts API"
A lot of people want to find an official API for managing Rollouts. There isn't any separate Argo Rollouts API. You can always use the Kubernetes API and patching of resources if you want to control a rollout.
But as explained in the previous point the end goal should be fully automated deployments without you having to tell Argo Rollouts to promote or abort.
## Integrating with other systems and processes
There are two main ways to integrate other systems with Argo Rollouts.
The easiest way is to use [Notifications](../features/notifications). This means that when a rollout is finished/aborted you send a notification to another system that does other tasks that you want to happen.
Alternatively you can control Rollouts with the CLI or by patching manually the Kubernetes resources.
## Use the Kubernetes Downward API
If you want your applications to know if they are part of a canary or not, you can use [Ephemeral labels](../features/ephemeral-metadata) along with the [Kubernetes downward api](https://kubernetes.io/docs/concepts/workloads/pods/downward-api/).
This means that your application will read from files its configuration in a dynamic manner and adapt according to the situation.
## Ingress desired/stable host routes
@ -19,7 +102,7 @@ to the ingress rules so that it is possible to specifically reach to the desired
pods or stable pods.
```yaml
apiVersion: networking.k8s.io/v1beta1
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: guestbook
@ -29,35 +112,79 @@ spec:
- host: guestbook-desired.argoproj.io
http:
paths:
- backend:
serviceName: guestbook-desired
servicePort: 443
path: /*
- path: /
pathType: Prefix
backend:
service:
name: guestbook-desired
port:
number: 443
# host rule to only reach the stable pods
- host: guestbook-stable.argoproj.io
http:
paths:
- backend:
serviceName: guestbook-stable
servicePort: 443
path: /*
- path: /
pathType: Prefix
backend:
service:
name: guestbook-stable
port:
number: 443
# default rule which omits host, and will split traffic between desired vs. stable
- http:
paths:
- backend:
serviceName: guestbook-root
servicePort: 443
path: /*
- path: /
pathType: Prefix
backend:
service:
name: guestbook-root
port:
number: 443
```
The above technique has the a benefit in that it would not incur additional cost of allocating
The above technique has a benefit in that it would not incur additional cost of allocating
additional load balancers.
## Reducing operator memory usage
On clusters with thousands of rollouts memory usage for the argo-rollouts
operator can be reduced significantly by changing RevisionHistoryLimit from the
default of 10 to a lower number. One user of Argo Rollouts saw a 27% reduction
in memory usage for a cluster with 1290 rollouts by changing
RevisionHistoryLimit from 10 to 0.
controller can be reduced significantly by changing the `RevisionHistoryLimit` property from the
default of 10 to a lower number.
One user of Argo Rollouts saw a 27% reduction
in memory usage for a cluster with 1290 rollouts by changing
`RevisionHistoryLimit` from 10 to 0.
## Rollout a ConfigMap change
Argo Rollouts is meant to work on a Kubernetes Deployment. When a ConfigMap is mounted inside one the Deployment container and a change occurs inside the ConfigMap, it won't trigger a new Rollout by default.
One technique to trigger the Rollout it to name dynamically the ConfigMap.
For example, adding a hash of its content at the end of the name:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: my-config-7270e14e6
```
Each time a change occurs in the ConfigMap, its name will change in the Deployment reference as well, triggering a Rollout.
However, it's not enough to perform correctly progressive rollouts, as the old ConfigMap might get deleted as soon as the new one is created. This would prevent Experiments and rollbacks in case of rollout failure to work correctly.
While no magical solution exist to work aroud that, you can tweak your deployment tool to remove the ConfigMap only when the Rollout is completed successfully.
A Rollout is Kubernetes workload resource which is equivalent to a Kubernetes Deployment object.
It is intended to replace a Deployment object in scenarios when more advanced deployment or
It is intended to replace a Deployment object in scenarios when more advanced deployment or
progressive delivery functionality is needed. A Rollout provides the following features which
a Kubernetes Deployment cannot:
@ -17,17 +17,17 @@ a Kubernetes Deployment cannot:
Progressive delivery is the process of releasing updates of a product in a controlled and gradual
manner, thereby reducing the risk of the release, typically coupling automation and metric analysis
to drive the automated promotion or rollback of the update.
to drive the automated promotion or rollback of the update.
Progressive delivery is often described as an evolution of continuous delivery, extending the
speed benefits made in CI/CD to the deployment process. This is accomplished by limiting the
exposure of the new version to a subset of users, observing and analyzing for correct behavior,
exposure of the new version to a subset of users, observing and analyzing for correct behavior,
then progressively increasing the exposure to a broader and wider audience while continuously
verifying correctness.
## Deployment Strategies
While the industry has used a consistent terminology to describe various deployment strategies, the implementations of these strategies tend to differ across tooling. To make it clear how the Argo Rollouts will behave, here are the descriptions of the various deployment strategies implementations offered by the Argo Rollouts.
While the industry has used a consistent terminology to describe various deployment strategies, the implementations of these strategies tend to differ across tooling. To make it clear how the Argo Rollouts will behave, here are the descriptions of the various deployment strategy implementations. Argo Rollouts only supports Blue-Green and Canary.
### Rolling Update
A `RollingUpdate` slowly replaces the old version with the new version. As the new version comes up, the old version is scaled down in order to maintain the overall count of the application. This is the default strategy of the Deployment object.
@ -46,4 +46,33 @@ A Canary deployment exposes a subset of users to the new version of the applicat
The picture above shows a canary with two stages (10% and 33% of traffic goes to new version) but this is just an example. With Argo Rollouts you can define the exact number of stages
and percentages of traffic according to your use case.
and percentages of traffic according to your use case.
## Which strategy to choose
In general Blue/Green is the easier strategy to start with, but also the more limited. We recommend you start with Blue/Green deployments first and as you gain confidence for your metrics and applications switch to Canaries.
You also need to examine if your application can handle canaries or not.
* Blue/Green always works because only one application is active at a time. Not all applications can have different versions running in parallel at the same time (which is what canaries are doing). This can be a showstopper for adopting canary deployments especially for legacy applications.
* Blue/Green is simpler because you can get their full value WITHOUT a traffic manager. While canaries can also work without a traffic manager, most of their advanced features assume a fine-grained way to control traffic. If you don't have a traffic manager, then you can easily get the full value
of blue/green deployments but only the basic capabilities of canaries.
* Blue/Green also works with services that use queues and databases (workers that fetch tasks). Argo Rollouts doesn't control traffic flow for
connections it doesn't understand (i.e. binary/queue channels).
Here is a summary table for the possible approaches.
The same limitations as for the multiple templates feature apply.
The controller will error when merging the templates if:
* Multiple metrics in the templates have the same name
* Two arguments with the same name have different default values no matter the argument value in Rollout
However, if the same AnalysisTemplate is referenced several times along the chain of references, the controller will only keep it once and discard the other references.
## Analysis Template Arguments
AnalysisTemplates may declare a set of arguments that can be passed by Rollouts. The args can then be used as in metrics configuration and are resolved at the time the AnalysisRun is created. Argument placeholders are defined as
@ -575,6 +759,67 @@ The entire analysis run is considered as Failed after three failed measurements.
))
```
## ConsecutiveSuccessLimit and FailureLimit
!!! important
`consecutiveSuccessLimit` available since v1.8
You can use either `failureLimit` to define a limit for the number of failures before the analysis is considered failed, `consecutiveSuccessLimit` to define the required consecutive number of successes for the analysis to succeed, or both together. One of them has to be applicable (i.e. not disabled, see below for more), otherwise a validation error is thrown.
To disable:
* `failureLimit`, set the field to `-1`.
* `consecutiveSuccessLimit`, set the field to `0` (the default value).
The default value for both is `0`, the meaning of which differs for each one of them. A value of `0` for `failureLimit` means its logic _is_ applicable and no failures are tolerated. However, a value of `0` for `consecutiveSuccessLimit` means it's inapplicable or disabled.
Let's go through each case and show what the behavior would look like.
### Only FailureLimit applicable
The behavior is shown above in the [Failure Conditions and Failure Limit](#failure-conditions-and-failure-limit) section. This is the default behavior if you set nothing of the two fields (with `failureLimit` having a default value of `0`, so no failures are tolerated).
### Only ConsecutiveSuccessLimit applicable
To have this behavior, you need to have something like
```yaml
failureLimit: -1
consecutiveSuccessLimit: 4 # Any value > 0
```
This behavior is essentially waiting for a condition to hold, or an event to happen. That is, keep measuring a metric and keep failing until you measure `N` consecutive successful measurements, at which point the analysis concludes successfully. This can be useful as an event-driven way of promoting a rollout when used in an inline analysis.
### Both FailureLimit and ConsecutiveSuccessLimit applicable
To have this behavior, you need to have something like
```yaml
failureLimit: 3 # Any value >= 0
consecutiveSuccessLimit: 4 # Any value > 0
```
The behavior is simply waiting to measure `N` consecutive successful measurements, _while_ being limited by the number of overall failures specified by `failureLimit`. Above, we need to have at most 3 failures before we get 4 consecutive successful measurements for the analysis to be considered successful.
In case of an analysis that has `count` specified (that is, runs for a specific amount of time) and that `count` is reached, the evaluation of success is as follows:
* `failureLimit` is violated and `consecutiveSuccessLimit` is satisfied: Failure.
* `failureLimit` is violated and `consecutiveSuccessLimit` is not satisfied: Failure.
* `failureLimit` is not violated and `consecutiveSuccessLimit` is satisfied: Success.
* `failureLimit` is not violated and `consecutiveSuccessLimit` is not satisfied: Inconclusive State.
As illustrated, `failureLimit` takes priority if violated. However, if neither is violated/satisfied, the analysis reaches an inconclusive state.
!!! note
When terminating analyses prematurely, they are always terminated successfully, unless it happens that `failureLimit` is enabled and violated, then they terminate in failure. `consecutiveSuccessLimit`, if enabled, doesn't affect the termination status.
For more clarity, examples of analyses terminated "prematurely":
* A background analysis with `count` not specified when terminated at the end of the rollout.
* Any analysis with `count` specified and not yet reached when the rollout is aborted.
## Dry-Run Mode
!!! important
@ -854,6 +1099,24 @@ spec:
limit: 20
```
## Time-to-live (TTL) Strategy
!!! important
Available since v1.7
`ttlStrategy` limits the lifetime of an analysis run that has finished execution depending on if it Succeeded or Failed. If this struct is set, once the run finishes, it will be deleted after the time to live expires. If this field is unset, the analysis controller will keep the completed runs, unless they are associated with rollouts using other garbage collection policies (e.g. `successfulRunHistoryLimit` and `unsuccessfulRunHistoryLimit`).
```yaml
apiVersion: argoproj.io/v1alpha1
kind: AnalysisRun
spec:
...
ttlStrategy:
secondsAfterCompletion: 3600
secondsAfterSuccess: 1800
secondsAfterFailure: 1800
```
## Inconclusive Runs
Analysis runs can also be considered `Inconclusive`, which indicates the run was neither successful,
@ -888,7 +1151,7 @@ A use case for having `Inconclusive` analysis runs are to enable Argo Rollouts t
whether or not measurement value is acceptable and decide to proceed or abort.
## Delay Analysis Runs
If the analysis run does not need to start immediately (i.e give the metric provider time to collect
If the analysis run does not need to start immediately (i.e. give the metric provider time to collect
metrics on the canary version), Analysis Runs can delay the specific metric analysis. Each metric
can be configured to have a different delay. In additional to the metric specific delays, the rollouts
with background analysis can delay creating an analysis run until a certain step is reached
@ -31,6 +31,7 @@ You can learn more about anti-affinity [here](https://kubernetes.io/docs/concept
Repeating the above example with anti-affinity enabled, here is what happens when the `.spec.template` of the Rollout changes. Due to anti-affinity, the new pods cannot be scheduled on nodes which run the old ReplicaSet's pods.
As a result, the cluster auto-scaler must create 2 nodes to host the new ReplicaSet's pods. In this case, pods won't be started since the scaled-down nodes are guaranteed to not have the new pods.

## Enabling Anti-Affinity in Rollouts
@ -41,7 +42,7 @@ This feature will not modify any of the ReplicaSet's pre-existing affinity rules
Users have a choice between these scheduling rules: `RequiredDuringSchedulingIgnoredDuringExecution` and `PreferredDuringSchedulingIgnoredDuringExecution`.
`RequiredDuringSchedulingIgnoredDuringExecution` requires a new version's pods to be on a separate node than the previous versions. If this
is not possible, the the new version's pods will not be scheduled.
is not possible, the new version's pods will not be scheduled.
A Blue Green Deployment allows users to reduce the amount of time multiple versions running at the same time.
A Blue Green Deployment allows users to reduce the amount of time multiple versions are running at the same time.
## Overview
@ -11,6 +11,12 @@ When there is a change to the `.spec.template` field of a rollout, the controlle
!!! important
When the rollout changes the selector on a service, there is a propagation delay before all the nodes update their IP tables to send traffic to the new pods instead of the old. During this delay, traffic will be directed to the old pods if the nodes have not been updated yet. In order to prevent the packets from being sent to a node that killed the old pod, the rollout uses the scaleDownDelaySeconds field to give nodes enough time to broadcast the IP table changes.
!!! important
ALB Ingress with Rollouts blue-green strategy is not supported without a chance of downtime.
When using an AWS ALB to route traffic to a service, the ALB Ingress Controller does not update the target groups in an atomic or safe manner. This can result in a situation where, during a deployment, the stable target group temporarily has no pods registered. This occurs because the ALB Controller removes all current pods from the target group before registering pods from the desired ReplicaSet.
The desired pods must pass their initial configured health check on the stable target group to be considered healthy by the ALB. This creates a risk where the ALB may temporarily have no healthy pods registered to the target group, depending on the timing of deregistration and registration of new pods. This can lead to application downtime that the rollouts controller cannot prevent.
## Example
```yaml
@ -75,7 +81,7 @@ The following describes the sequence of events that happen during a blue-green u
1. Beginning at a fully promoted, steady-state, a revision 1 ReplicaSet is pointed to by both the `activeService` and `previewService`.
1. A user initiates an update by modifying the pod template (`spec.template.spec`).
1. The revision 2 ReplicaSet is created with size 0.
1. The preview service is modified to point to the revision 2 ReplicaSet. The `activeService` remains pointing to revision 1.
1. The `previewService` is modified to point to the revision 2 ReplicaSet. The `activeService` remains pointing to revision 1.
1. The revision 2 ReplicaSet is scaled to either `spec.replicas` or `previewReplicaCount` if set.
1. Once revision 2 ReplicaSet Pods are fully available, `prePromotionAnalysis` begins.
1. Upon success of `prePromotionAnalysis`, the blue/green pauses if `autoPromotionEnabled` is false, or `autoPromotionSeconds` is non-zero.
@ -93,12 +99,12 @@ The AutoPromotionEnabled will make the rollout automatically promote the new Rep
Defaults to true
### autoPromotionSeconds
The AutoPromotionSeconds will make the rollout automatically promote the new ReplicaSet to active Service after the AutoPromotionSeconds time has passed since the rollout has entered a paused state. If the `AutoPromotionEnabled` field is set to false, this field will be ignored
Setting a positive non-zero value here would make the rollout automatically promote the new `ReplicaSet` to active Service after this much time has been elapsed since the rollout has entered a paused state. If the `AutoPromotionEnabled` field is set to **false**, this field would be ignored.
Defaults to nil
### antiAffinity
Check out the [Anti Affinity document](anti-affinity/anti-affinity.md) document for more information.
Check out the [Anti Affinity document](anti-affinity/anti-affinity.md) for more information.
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.
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 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 add 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 declaratively describe how they want to progress to the new version. Below is an example of a canary strategy.
There are multiple steps available, the most basic ones are `setWeight` and `pause`. The `setWeight` field dictates the percentage of traffic that should be sent to the canary, and the `pause` step instructs the rollout to pause. When the controller reaches a `pause` step for a rollout, it will add 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 declaratively 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 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.
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 41%, the Rollout attempts to get there by finding the whole number with the smallest delta, rounding up the calculation if the deltas are equals (i.e. the new ReplicaSet has 4 pods since 41% of 10 is closer to 4/10 than 5/10, and the old ReplicaSet has 6 pods). 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
apiVersion: argoproj.io/v1alpha1
kind: Rollout
@ -26,25 +30,26 @@ spec:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
ports:
- containerPort: 80
- name: nginx
image: nginx:1.15.4
ports:
- containerPort: 80
minReadySeconds: 30
revisionHistoryLimit: 3
strategy:
canary: #Indicates that the rollout should use the Canary strategy
maxSurge: "25%"
maxSurge: '25%'
maxUnavailable: 0
steps:
- setWeight: 10
- pause:
duration: 1h # 1 hour
- setWeight: 20
- pause: {} # pause indefinitely
- setWeight: 10
- pause:
duration: 1h # 1 hour
- setWeight: 20
- pause: {} # pause indefinitely
```
## Pause Duration
Pause duration can be specified with an optional time unit suffix. Valid time units are "s", "m", "h". Defaults to "s" if not specified.
```yaml
@ -52,14 +57,14 @@ spec:
strategy:
canary:
steps:
- pause: { duration: 10 } # 10 seconds
- pause: { duration: 10 } # 10 seconds
- pause: { duration: 10s } # 10 seconds
- pause: { duration: 10m } # 10 minutes
- pause: { duration: 10h } # 10 hours
- pause: {} # pause indefinitely
- pause: {} # pause indefinitely
```
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.
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
@ -81,31 +86,31 @@ match the traffic weight. Some use cases for this:
the canary, while setWeight is still set to 0.
3. You wish to scale the canary up to 100%, in order to facilitate traffic shadowing.
!!! important
Setting canary scale is only available when using the canary strategy with a traffic router, since the basic canary needs to control canary scale in order to approximate canary weight.
To control canary scales and weights during steps, use the `setCanaryScale` step and indicate which scale the
To control canary scales and weights during steps, use the `setCanaryScale` step and indicate which scale
the canary should use:
* explicit replica count without changing traffic weight (`replicas`)
* explicit weight percentage of total spec.replicas without changing traffic weight(`weight`)
* to or not to match current canary's `setWeight` step (`matchTrafficWeight: true or false`)
- explicit replica count without changing traffic weight (`replicas`)
- explicit weight percentage of total spec.replicas without changing traffic weight(`weight`)
- to or not to match current canary's `setWeight` step (`matchTrafficWeight: true or false`)
```yaml
spec:
strategy:
canary:
steps:
# explicit count
- setCanaryScale:
replicas: 3
# a percentage of spec.replicas
- setCanaryScale:
weight: 25
# matchTrafficWeight returns to the default behavior of matching the canary traffic weight
- setCanaryScale:
matchTrafficWeight: true
# explicit count
- setCanaryScale:
replicas: 3
# a percentage of spec.replicas
- setCanaryScale:
weight: 25
# matchTrafficWeight returns to the default behavior of matching the canary traffic weight
- setCanaryScale:
matchTrafficWeight: true
```
When using `setCanaryScale` with explicit values for either replicas or weight, one must be careful
@ -119,12 +124,12 @@ spec:
strategy:
canary:
steps:
# 1 canary pod (10% of spec.replicas)
- setCanaryScale:
weight: 10
# 90% of traffic to the 1 canary pod
- setWeight: 90
- pause: {}
# 1 canary pod (10% of spec.replicas)
- setCanaryScale:
weight: 10
# 90% of traffic to the 1 canary pod
- setWeight: 90
- pause: {}
```
The above situation is caused by the changed behvaior of `setWeight` after `setCanaryScale`. To reset, set `matchTrafficWeight: true` and the `setWeight` behavior will be restored, i.e., subsequent `setWeight` will create canary replicas matching the traffic weight.
@ -132,6 +137,7 @@ The above situation is caused by the changed behvaior of `setWeight` after `setC
## Dynamic Stable Scale (with Traffic Routing)
!!! important
Available since v1.1
When using traffic routing, by default the stable ReplicaSet is left scaled to 100% during the update.
@ -167,11 +173,12 @@ spec:
abortScaleDownDelaySeconds: 600
```
## 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.
## Other Configurable Features
Here are the optional fields that will modify the behavior of canary strategy:
```yaml
@ -188,36 +195,43 @@ spec:
```
### analysis
Configure the background [Analysis](analysis.md) to execute during the rollout. If the analysis is unsuccessful the rollout will be aborted.
Configure the background [Analysis](../analysis.md) to execute during the rollout. If the analysis is unsuccessful the rollout will be aborted.
Defaults to nil
### antiAffinity
Check out the [Anti Affinity document](anti-affinity/anti-affinity.md) document for more information.
Check out the [Anti Affinity](../anti-affinity/anti-affinity.md) document for more information.
Defaults to nil
### canaryService
`canaryService` references a Service that will be modified to send traffic to only the canary ReplicaSet. This allows users to only hit the canary ReplicaSet.
Defaults to an empty string
### stableService
`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
### maxSurge
`maxSurge` defines the maximum number of replicas the rollout can create to move to the correct ratio set by the last setWeight. Max Surge can either be an integer or percentage as a string (i.e. "20%")
Defaults to "25%".
### maxUnavailable
The maximum number of pods that can be unavailable during the update. Value can be an absolute number (ex: 5) or a percentage of desired pods (ex: 10%). This can not be 0 if MaxSurge is 0.
Defaults to 25%
### trafficRouting
The [traffic management](traffic-management/index.md) rules to apply to control the flow of traffic between the active and canary versions. If not set, the default weighted pod replica based routing will be used.
The [traffic management](../traffic-management/index.md) rules to apply to control the flow of traffic between the active and canary versions. If not set, the default weighted pod replica based routing will be used.
This is an experimental, [alpha-quality](https://github.com/argoproj/argoproj/blob/main/community/feature-status.md#alpha)
feature that allows you to execute plugins during canary steps.
Argo Rollouts supports getting step plugins via 3rd party [plugin system](../../plugins.md). This allows users to extend the capabilities of Rollouts
to support executing arbitrary steps during the canary. Rollout's uses a plugin library called
[go-plugin](https://github.com/hashicorp/go-plugin) to do this.
## Installing
There are two methods of installing and using an Argo Rollouts plugin. The first method is to mount up the plugin executable
into the rollouts controller container. The second method is to use an HTTP(S) server to host the plugin executable.
### Mounting the plugin executable into the rollouts controller container
There are a few ways to mount the plugin executable into the rollouts controller container. Some of these will depend on your
particular infrastructure. Here are a few methods:
- Using an init container to download the plugin executable
- Using a Kubernetes volume mount with a shared volume such as NFS, EBS, etc.
- Building the plugin into the rollouts controller container
Then you can use the ConfigMap to point to the plugin executable file location. Example:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: argo-rollouts-config
data:
stepPlugins: |-
- name: "argoproj-labs/sample-step" # name of the plugin, it must match the name required by the plugin so it can find its configuration
location: "file://./my-custom-plugin" # supports http(s):// urls and file://
```
### Using an HTTP(S) server to host the plugin executable
!!! warning "Installing a plugin with http(s)"
Depending on which method you use to install and the plugin, there are some things to be aware of.
The rollouts controller will not start if it can not download or find the plugin executable. This means that if you are using
a method of installation that requires a download of the plugin and the server hosting the plugin for some reason is not available and the rollouts
controllers pod got deleted while the server was down or is coming up for the first time, it will not be able to start until
the server hosting the plugin is available again.
Argo Rollouts will download the plugin at startup only once but if the pod is deleted it will need to download the plugin again on next startup. Running
Argo Rollouts in HA mode can help a little with this situation because each pod will download the plugin at startup. So if a single pod gets
deleted during a server outage, the other pods will still be able to take over because there will already be a plugin executable available to it. It is the
responsibility of the Argo Rollouts administrator to define the plugin installation method considering the risks of each approach.
Argo Rollouts supports downloading the plugin executable from an HTTP(S) server. To use this method, you will need to
configure the controller via the `argo-rollouts-config` ConfigMap and set `pluginLocation` to a http(s) url. Example:
```yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: argo-rollouts-config
data:
stepPlugins: |-
- name: "argoproj-labs/sample-nginx" # name of the plugin, it must match the name required by the plugin so it can find its configuration
location: "https://github.com/argoproj-labs/rollouts-plugin-trafficrouter-sample-nginx/releases/download/v0.0.1/metric-plugin-linux-amd64" # supports http(s):// urls and file://
sha256: "08f588b1c799a37bbe8d0fc74cc1b1492dd70b2c" # optional sha256 checksum of the plugin executable
```
### Disabling a plugin
A step plugin that will execute during your Rollouts will fail the canary deployment whenever there is an unhandled error.
If a step plugin is used in multiple rollouts and is suddenly unstable, none of the rollouts will be able to progress.
To make the plugin less disruptive and the upgrades easier, you can use the `disabled` flag in the plugin configuration to
disable it globally. This will skip the plugin execution in every Rollout where it is configured, and progress to the next canary step.
disabled: true # Skip all canary steps using this plugin because it may be faulty.
```
## Usage
You can execute a configured step plugin at any point during your canary steps.
The plugin will be executed and the rollout step will be progressing until the plugin execution returns a status of
`Successful`, `Failed` or `Error`. Once completed, the rollout will progress to the next configured step.
For the available plugin `config`, refer to each specific plugin documentation.
```yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: example-plugin-ro
spec:
strategy:
canary:
steps:
- plugin:
name: argoproj-labs/step-exec
config:
command: echo "hello world"
```
### Plugin Statuses
To know the result of your plugin, you can use the `status.stepPluginStatuses[]` property to find the status that correspond to
your execution. Each status item is unique by `index`, `name` and `operation`. The `operation` can be one of the following:
- `Run`: The main operation that execute the plugin.
- `Terminate`: The operation called on your plugin when the `Run` operation is still ongoing, but your rollout is aborted.
- `Abort`: The operation called on your plugin when it is aborted. This will be called for every `Successful``Run` operation.
## Implementation
As a plugin developer, your step plugin should follow some conventions to make it predictable and easier to use.
### Run operation
The run operation is the method called on your plugin when executed. The operation can be called
**multiple times**. It is the responsibility of the plugin's implementation to validate if the desired
plugin actions were already taken or not.
#### Long-running operations
If the plugin needs to execute an operation that may take a long time, or poll for a result, it can return
early with a `Running` phase and a `RequeueAfter` duration. The controller will requeue the rollout and call the `Run` operation
again after the `RequeueAfter` has expired. The `Status` property on the return object can hold any information that would be
necessary to retrieve the state in subsequent executions.
### Terminate operation
If the `Run` operation returns with a `Running` phase and the rollout needs to cancel the execution, the controller will call the plugin's terminate method
with the state of the ongoing `Running` operation. The plugin can use this method to cancel any ongoing information.
This is often called if the rollout is fully promoted during a plugin execution.
If the terminate operation has an error and fails, it will not be retried. The plugin should have a mechanism to cancel
suspiciously long-running operations if necessary.
### Abort operation
The abort operation will be called whenever a rollout is aborted and plugin step `Run` operation was `Successful` or currently `Running`.
The operation will be called in the reverse execution order with the existing state of the operation it is aborting.
If the abort operation has an error and fails, it will not be retried. The plugin should have a mechanism to cancel
suspiciously long-running operations if necessary.
### Returning errors
The plugin can return an error for unhandled operations. In that case, the rollout will handle that error and apply a
backoff mechanism to retry the execution of the plugin until it returns `Successful` or `Failed` phase. When an error happens, the
`Status` returned by the plugin is not persisted, allowing it to retry later on the last known valid status.
The controller will keep retrying until it succeeds, or the rollout is aborted.
## List of Available Plugins (alphabetical order)
If you have created a plugin, please submit a PR to add it to this list.
This is an **optional** feature of Argo Rollouts that allows you to have more visibility while a rollout is in progress. You do **NOT** need to use emphemeral metadata in order to achieve the main functionality of Argo Rollouts.
!!! important
Normally during a deployment, Argo Rollouts automatically handles the pods of the new and old versions along with their labels and their association with your traffic provider (if you use one).
Available for blue-green rollouts since v1.0
In some scenarios however,
One use case is for a Rollout to label or annotate the desired/stable pods with user-defined
1. You might want to annotate the pods of each version with your own custom labels
1. You may want the application itself know when a deployment is happening
Argo Rollouts gives you the capability to label or annotate the desired/stable pods with user-defined
labels/annotations, for _only_ the duration which they are the desired or stable set, and for the
labels to be updated/removed as soon as the ReplicaSet switches roles (e.g. from desired to stable).
The use case which this enables, is to allow prometheus, wavefront, datadog queries and dashboards
to be built, which can rely on a consistent labels, rather than the `rollouts-pod-template-hash`
In the first use case this allows prometheus, wavefront, datadog queries and dashboards
to be built, which can rely on a consistent list of labels, rather than the `rollouts-pod-template-hash`
which is unpredictable and changing from revision to revision.
In the second use case you can have your application read the labels itself using the [Kubernetes Downward API](https://kubernetes.io/docs/concepts/workloads/pods/downward-api/) and adjust
its behavior automatically only for the duration of the canary/blue/green deployment. For example you could point your application
to a different Queue server while the application pods are in "preview" and only use the production instance of your Queue server
when the pods are marked as "stable".
## Using Ephemeral labels
A Rollout using the canary strategy has the ability to attach ephemeral metadata to the stable or
canary Pods using the `stableMetadata` and `canaryMetadata` fields respectively.
@ -47,12 +59,14 @@ spec:
During an update, the Rollout will create the desired ReplicaSet while also merging the metadata
defined in `canaryMetadata`/`previewMetadata` to the desired ReplicaSet's `spec.template.metadata`.
This results in all Pods of the ReplicaSet being created with the desired metadata. When the rollout
This results in all Pods of the ReplicaSet being created with the desired metadata.
When the rollout
becomes fully promoted, the desired ReplicaSet becomes the stable, and is updated to use the labels
and annotations under `stableMetadata`/`activeMetadata`. The Pods of the ReplicaSet will then be
updated _in place_ to use the stable metadata (without recreating the pods).
!!! important
!!! tip
In order for tooling to take advantage of this feature, they would need to recognize the change in
labels and/or annotations that happen _after_ the Pod has already started. Not all tools may detect
this.
this. For application code apart from the Kubernetes Downward API you also need a programming library that automatically reloads configuration files when they change their contents.
- With Kustomize 4.5.5 kustomize can use kubernetes OpenAPI data to get merge key and patch strategy information about [resource types](https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/openapi). For example, given the following rollout:
The OpenAPI data is auto-generated and defined in this [file](https://github.com/argoproj/argo-schema-generator/blob/main/schema/argo_all_k8s_kustomize_schema.json).
# If you want to controll multiple ingress resources you can use the ingresses field, if ingresses is specified
# the ingress field will need to be omitted.
ingresses:
ingresses:
- ingress-1
- ingress-2
# Reference to a Service that the Ingress must target in one of the rules (optional).
@ -66,7 +66,7 @@ spec:
The referenced Ingress should be deployed with an ingress rule that matches the Rollout service:
```yaml
apiVersion: networking.k8s.io/v1beta1
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress
@ -76,14 +76,17 @@ spec:
rules:
- http:
paths:
- path: /*
- path: /
pathType: Prefix
backend:
# serviceName must match either: canary.trafficRouting.alb.rootService (if specified),
# or canary.stableService (if rootService is omitted)
serviceName: root-service
# servicePort must be the value: use-annotation
# This instructs AWS Load Balancer Controller to look to annotations on how to direct traffic
servicePort: use-annotation
service:
# serviceName must match either: canary.trafficRouting.alb.rootService (if specified),
# or canary.stableService (if rootService is omitted)
name: root-service
# servicePort must be the value: use-annotation
# This instructs AWS Load Balancer Controller to look to annotations on how to direct traffic
port:
name: use-annotation
```
During an update, the rollout controller injects the `alb.ingress.kubernetes.io/actions.<SERVICE-NAME>`
@ -95,7 +98,7 @@ annotation that splits traffic between the canary-service and stable-service, wi
of 10 and 90 respectively:
```yaml
apiVersion: networking.k8s.io/v1beta1
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress
@ -123,10 +126,13 @@ spec:
rules:
- http:
paths:
- path: /*
- path: /
pathType: Prefix
backend:
serviceName: root-service
servicePort: use-annotation
service:
name: root-service
port:
name: use-annotation
```
!!! note
@ -143,7 +149,7 @@ spec:
By default, a rollout will inject the `alb.ingress.kubernetes.io/actions.<SERVICE-NAME>` annotation
using the service/action name specified under `spec.strategy.canary.stableService`. However, it may
be desirable to specify an explicit service/action name different from the `stableService`. For
example, [one pattern](/argo-rollouts/best-practices/#ingress-desiredstable-host-routes) is to use a single
example, [one pattern](/best-practices/#ingress-desiredstable-host-routes) is to use a single
Ingress containing three different rules to reach the canary, stable, and root service separately
(e.g. for testing purposes). In this case, you may want to specify a "root" service as the
service/action name instead of stable. To do so, reference a service under `rootService` under the
@ -302,6 +308,9 @@ spec:
args: [--aws-verify-target-group]
# NOTE: in v1.0, the --alb-verify-weight flag should be used instead
```
!!! note
The `--aws-region` flag is mandatory for enabling AWS integrations, including TargetGroup verification. If the Argo Rollouts controller does not have the correct AWS region specified, or lacks access to validate the AWS ALB, the promotion process will fail. Ensure that the necessary AWS API permissions are granted to the controller and that the region is correctly configured.
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):
@ -411,7 +420,7 @@ spec:
By default, Argo Rollout will operate on Ingresses with the annotation:
@ -65,7 +65,7 @@ When Ambassador is configured in the `trafficRouting` attribute of the manifest,
## Endpoint Resolver
By default, Ambassador uses kube-proxy to route traffic to Pods. However we should configure it to bypass kube-proxy and route traffic directly to pods. This will provide true L7 load balancing which is desirable in a canary workflow. This approach is called [endpoint routing](https://www.getambassador.io/docs/latest/topics/running/load-balancer/) and can be achieve by configuring [endpoint resolvers](https://www.getambassador.io/docs/latest/topics/running/resolvers/#the-kubernetes-endpoint-resolver).
By default, Ambassador uses kube-proxy to route traffic to Pods. However we should configure it to bypass kube-proxy and route traffic directly to pods. This will provide true L7 load balancing which is desirable in a canary workflow. This approach is called [endpoint routing](https://www.getambassador.io/docs/latest/topics/running/load-balancer/) and can be achieved by configuring [endpoint resolvers](https://www.getambassador.io/docs/latest/topics/running/resolvers/#the-kubernetes-endpoint-resolver).
To configure Ambassador to use endpoint resolver it is necessary to apply the following resource in the cluster:
When using Istio only traffic that is within the service mesh will follow the rollout strategy. Pods excluded from the service mesh (e.g., because of a `sidecar.istio.io/inject="false"` label) will follow default Kubernetes traffic routing.
## Host-level Traffic Splitting
The first approach to traffic splitting using Argo Rollouts and Istio, is splitting between two
@ -303,7 +307,7 @@ spec:
## Multicluster Setup
If you have [Istio multicluster setup](https://istio.io/latest/docs/setup/install/multicluster/)
where the primary Istio cluster is different than the cluster where the Argo Rollout controller
where the primary Istio cluster is different from the cluster where the Argo Rollout controller
is running, then you need to do the following setup:
1. Create a `ServiceAccount` in the Istio primary cluster.
@ -439,12 +443,12 @@ leverage the following Argo CD features:
ignoreDifferences:
- group: networking.istio.io
kind: VirtualService
jsonPointers:
- /spec/http/0
jqPathExpressions:
- .spec.http[].route[].weight
```
Ignoring the differences in the VirtualServices HTTP route, prevents gitops differences
in the VirtualService HTTP routes to contribute to the overall sync status of the Argo CD
Ignoring the differences in the VirtualServices HTTP route weights, prevents GitOps differences
in the VirtualService HTTP route weights to contribute to the overall sync status of the Argo CD
application. This adds the additional benefit of prevent auto-sync operations from being
triggered.
@ -459,6 +463,7 @@ leverage the following Argo CD features:
syncPolicy:
syncOptions:
- ApplyOutOfSyncOnly=true
- RespectIgnoreDifferences=true
```
By default, when Argo CD syncs an application, it runs `kubectl apply` against all resources in
@ -468,10 +473,17 @@ leverage the following Argo CD features:
feature, provides a way to manage the conflict in the desired state of a VirtualService between
Argo CD and Argo Rollouts.
Argo CD also has an [open issue here](https://github.com/argoproj/argo-cd/issues/2913) which would
help address this problem. The proposed solution is to introduce an annotation to resources, which
indicates to Argo CD to respect and preserve the differences at a specified path, in order to allow
other controllers (e.g. Argo Rollouts) controller manage them instead.
## Ping Pong
!!! important
Available since v1.7
Argo Rollouts also supports ping pong when using Istio this was added to support configuring both ALB and
Istio traffic routers at the same time. When using an ALB, ping-pong is generally a best practice especially with ALB readiness
gates enabled. However, when we change the service selectors when a rollout is aborted back to stable pod hash it causes a blip
of traffic outage because the ALB controller will set the pod readiness gates to false for a short while due to the label changes.
If we configure both ALB and Istio with ping-pong this selector change does not happen and hence we do not see any outages.
@ -7,7 +7,8 @@ The Rollout controller will always set the following two annotations on the cana
- `canary: true` to indicate that this is the canary Ingress
- `canary-weight: <num>` to indicate what percentage of traffic to send to the canary. If all traffic is routed to the stable Service, this is set to `0`
You can provide additional annotations to add to the canary Ingress via the `additionalIngressAnnotations` field to enable features like routing by header or cookie.
You can provide additional annotations to add to the canary Ingress via the `additionalIngressAnnotations` or `canaryIngressAnnotations` field to enable features like routing by header or cookie.
While the former offers the possibility of reusing a common, injectable nginx annotation prefix, the latter allows defining custom full annotations of any group, which may be relevant for other, independent mechanisms, such as a third-party metrics scraper or some other infrastructure integration.
## Integration with Argo Rollouts
@ -34,6 +35,8 @@ spec:
additionalIngressAnnotations: # optional
canary-by-header: X-Canary
canary-by-header-value: iwantsit
canaryIngressAnnotations: # optional
my-custom-annotation.mygroup.com/key: value
```
The stable Ingress field is a reference to an Ingress in the same namespace of the Rollout. The Rollout requires the primary Ingress routes traffic to the stable Service. The Rollout checks that condition by confirming the Ingress has a backend that matches the Rollout's stableService.
@ -42,6 +45,8 @@ The controller routes traffic to the canary Service by creating a second Ingress
Since the Nginx Ingress controller allows users to configure the annotation prefix used by the Ingress controller, Rollouts can specify the optional `annotationPrefix` field. The canary Ingress uses that prefix instead of the default `nginx.ingress.kubernetes.io` if the field set.
If full annotations, [as defined in the Kubernetes docs](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/#syntax-and-character-set), perhaps from different groups, need to be declared instead, the `canaryIngressAnnotations` field can be used, which accepts a similar key-value structure, but performs no prefix injection.
Note that, in case of collision with `additionalIngressAnnotations`, the value under `canaryIngressAnnotations` prevails.
## Using Argo Rollouts with multiple NGINX ingress controllers per service
Starting with v1.5, argo rollouts supports multiple Nginx ingress controllers pointing at one service with canary deployments. If only one ingress controller is needed, utilize the existing key `stableIngress`. If multiple ingress controllers are needed (e.g., separating internal vs external traffic), use the key `stableIngresses` instead. It takes an array of string values that are the names of the ingress controllers. Canary steps are applied identically across all ingress controllers.
Argo Rollouts supports getting analysis metrics via 3rd party plugin system. This allows users to extend the capabilities of Rollouts
to support metric providers that are not natively supported. Rollout's uses a plugin library called
This is an experimental, [alpha-quality](https://github.com/argoproj/argoproj/blob/main/community/feature-status.md#alpha)
feature that allows you to supporttraffic router that are not natively supported.
Argo Rollouts supports getting traffic router via 3rd party [plugin system](../../plugins.md). This allows users to extend the capabilities of Rollouts
to support traffic router that are not natively supported. Rollout's uses a plugin library called
[go-plugin](https://github.com/hashicorp/go-plugin) to do this. You can find a sample plugin
There are two methods of installing and using an argo rollouts plugin. The first method is to mount up the plugin executable
into the rollouts controller container. The second method is to use a HTTP(S) server to host the plugin executable.
into the rollouts controller container. The second method is to use an HTTP(S) server to host the plugin executable.
### Mounting the plugin executable into the rollouts controller container
There are a few ways to mount the plugin executable into the rollouts controller container. Some of these will depend on your
particular infrastructure. Here are a few methods:
* Using an init container to download the plugin executable
* Using a Kubernetes volume mount with a shared volume such as NFS, EBS, etc.
* Building the plugin into the rollouts controller container
- Using an init container to download the plugin executable
- Using a Kubernetes volume mount with a shared volume such as NFS, EBS, etc.
- Building the plugin into the rollouts controller container
Then you can use the configmap to point to the plugin executable file location. Example:
@ -31,13 +33,26 @@ metadata:
name: argo-rollouts-config
data:
trafficRouterPlugins: |-
- name: "argoproj-labs/sample-nginx" # name of the plugin, it must match the name required by the plugin so it can find it's configuration
- name: "argoproj-labs/sample-nginx" # name of the plugin, it must match the name required by the plugin so it can find its configuration
location: "file://./my-custom-plugin" # supports http(s):// urls and file://
```
### Using a HTTP(S) server to host the plugin executable
### Using an HTTP(S) server to host the plugin executable
Argo Rollouts supports downloading the plugin executable from a HTTP(S) server. To use this method, you will need to
!!! warning "Installing a plugin with http(s)"
Depending on which method you use to install and the plugin, there are some things to be aware of.
The rollouts controller will not start if it can not download or find the plugin executable. This means that if you are using
a method of installation that requires a download of the plugin and the server hosting the plugin for some reason is not available and the rollouts
controllers pod got deleted while the server was down or is coming up for the first time, it will not be able to start until
the server hosting the plugin is available again.
Argo Rollouts will download the plugin at startup only once but if the pod is deleted it will need to download the plugin again on next startup. Running
Argo Rollouts in HA mode can help a little with this situation because each pod will download the plugin at startup. So if a single pod gets
deleted during a server outage, the other pods will still be able to take over because there will already be a plugin executable available to it. It is the
responsibility of the Argo Rollouts administrator to define the plugin installation method considering the risks of each approach.
Argo Rollouts supports downloading the plugin executable from an HTTP(S) server. To use this method, you will need to
configure the controller via the `argo-rollouts-config` configmap and set `pluginLocation` to a http(s) url. Example:
```yaml
@ -47,34 +62,39 @@ metadata:
name: argo-rollouts-config
data:
trafficRouterPlugins: |-
- name: "argoproj-labs/sample-nginx" # name of the plugin, it must match the name required by the plugin so it can find it's configuration
- name: "argoproj-labs/sample-nginx" # name of the plugin, it must match the name required by the plugin so it can find its configuration
location: "https://github.com/argoproj-labs/rollouts-plugin-trafficrouter-sample-nginx/releases/download/v0.0.1/metric-plugin-linux-amd64" # supports http(s):// urls and file://
sha256: "08f588b1c799a37bbe8d0fc74cc1b1492dd70b2c" #optional sha256 checksum of the plugin executable
headersFrom: #optional headers for the download via http request
- secretRef:
name: secret-name
---
apiVersion: v1
kind: Secret
metadata:
name: secret-name
stringData:
Authorization: Basic <Base64TOKEN>
My-Header: value
```
## Some words of caution
Depending on which method you use to install and the plugin, there are some things to be aware of.
The rollouts controller will not start if it can not download or find the plugin executable. This means that if you are using
a method of installation that requires a download of the plugin and the server hosting the plugin for some reason is not available and the rollouts
controllers pod got deleted while the server was down or is coming up for the first time, it will not be able to start until
the server hosting the plugin is available again.
Argo Rollouts will download the plugin at startup only once but if the pod is deleted it will need to download the plugin again on next startup. Running
Argo Rollouts in HA mode can help a little with this situation because each pod will download the plugin at startup. So if a single pod gets
deleted during a server outage, the other pods will still be able to take over because there will already be a plugin executable available to it. It is the
responsibility of the Argo Rollouts administrator to define the plugin installation method considering the risks of each approach.
## List of Available Plugins (alphabetical order)
#### Add Your Plugin Here
* If you have created a plugin, please submit a PR to add it to this list.
* Provide support for Gateway API, which includes Kuma, Traefix, cilium, Contour, GloodMesh, HAProxy, and [many others](https://gateway-api.sigs.k8s.io/implementations/#implementation-status).
- This is a plugin that allows argo-rollouts to work with Consul's service mesh for traffic shaping patterns.
- This is a plugin that allows argo-rollouts to work with contour's resource: HTTPProxy. It enables traffic shaping patterns such as canary releases and more.
- Provide support for Gateway API, which includes Kuma, Traefix, cilium, Contour, GloodMesh, HAProxy, and [many others](https://gateway-api.sigs.k8s.io/implementations/#implementation-status).
The Cloud Native Computing Foundation [has archived the SMI Spec](https://www.cncf.io/blog/2023/10/03/cncf-archives-the-service-mesh-interface-smi-project/). The recommended way forward is to look at the [Gateway API](https://gateway-api.sigs.k8s.io/), [Project Gamma](https://gateway-api.sigs.k8s.io/concepts/gamma/) and the [Argo Rollouts Gateway API Plugin](https://github.com/argoproj-labs/rollouts-plugin-trafficrouter-gatewayapi).
[Service Mesh Interface](https://smi-spec.io/) (SMI) is a standard interface for service meshes on Kubernetes leveraged by many Service Mesh implementations (like Linkerd). SMI offers this functionality through a set of CRDs, and the Argo Rollouts controller creates these resources to manipulate the traffic routing into the desired state.
The Argo Rollout controller achieves traffic shaping by creating and manipulating the [TrafficSplit CR](https://github.com/servicemeshinterface/smi-spec/blob/master/traffic-split.md). A TrafficSplit describes the desired traffic routing for an application and relies on the underlying Service Meshes implement that desired state. Instead of worrying about the details of a specific service mesh, a user needs to specify a root Service that clients use to communicate and a list of backends consisting of a Service and weight. The Service Mesh implementing SMI uses this spec to route traffic to the backends Services based on the weights of the backends. For Rollout users, the Argo Rollout controller creates and manipulates the TrafficSplit using the following information:
- Canary Service: Name of the service that sends traffic only to the canary pods
- Stable Service: Name of the service that sends traffic only to the stable pods
- Stable Service: Name of the service that sends traffic only to the stable pods
- Root Service: Name of the service that clients use to communicate. If a request comes to this root service not through a proxy, the standard Kubernetes service routing will be used.
Below is an example of a Rollout with all the required fields configured:
Here we see the recommendation for cpu, memory with lowerbound, upper bound, Target etc., are provided. If we check the status of the pods.. the older pods with initial configuration would get terminated and newer pods get created.
Here we see the recommendation for cpu, memory with lowerbound, upper bound, Target etc., are provided. If we check the status of the pods, the older pods with initial configuration would get terminated and newer pods get created.
```yaml
# kubectl get po -n test-vpa -w
@ -337,7 +337,7 @@ Events:
## Requirements
In order for the VPA to manipulate the rollout, the Kubernetes cluster hosting the rollout CRD needs the subresources support for CRDs. This feature was introduced as alpha in Kubernetes version 1.10 and transitioned to beta in Kubernetes version 1.11. If a user wants to use VPA on v1.10, the Kubernetes Cluster operator will need to add a custom feature flag to the API server. After 1.10, the flag is turned on by default. Check out the following [link](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) for more information on setting the custom feature flag.
When installing VPA you may need to add the following in RBAC configurations for `system:vpa-target-reader` cluster role as by default VPA maynot support rollouts in all the versions.
When installing VPA you may need to add the following in RBAC configurations for `system:vpa-target-reader` cluster role as by default VPA maynot support rollouts in all the versions.