On a failed promotion the canary keeps serving, but the traffic may
already have been shifted to the primary by runPromotionTrafficShift
before it started failing. Route all traffic back to the canary and
report the matching canary weight instead of zeroing it.
Addresses review feedback on #1931.
Signed-off-by: Pedram Pourmohammad <eragon.pedy@gmail.com>
When the canary analysis succeeds, Flagger copies the canary pod spec
to the primary and waits for the primary rollout to finish. If the
primary fails to become ready, the non-retriable readiness error
triggered the standard analysis rollback, which routes all traffic to
the primary and scales the canary to zero.
During promotion the primary already runs the new (failing) spec while
the canary is the only healthy copy of the new revision still serving
traffic. Rolling back therefore sends all traffic to the broken primary
and deletes the working canary, taking the application down.
Halt the promotion instead: when the primary is not ready and the canary
is in the Promoting or Finalising phase, mark the rollout as failed and
alert, but keep the canary running and leave routing untouched until the
primary recovers or a corrected revision is applied.
Fixes#1898
Signed-off-by: Pedram Pourmohammad <eragon.pedy@gmail.com>
When skipAnalysis is enabled and the canary is promoted, the
post-rollout webhooks were not being executed. This fix ensures
that runPostRolloutHooks is called in shouldSkipAnalysis, matching
the behavior of the normal promotion path.
Fixesfluxcd/flagger#1195
Signed-off-by: Vishal Kumar Singh <vishal.kr.singh2021@gmail.com>
Implement flagger_canary_successes_total and flagger_canary_failures_total
counter metrics with deployment strategy detection and analysis status
tracking for better observability of canary deployment outcomes.
Signed-off-by: cappyzawa <cappyzawa@gmail.com>
Enhance existing scheduler tests for deployments, daemonsets, and
services by adding prometheus metrics verification using testutil.
This ensures that status metrics are correctly recorded during
canary promotion workflows and provides better test coverage for
the metrics recording functionality.
Signed-off-by: cappyzawa <cappyzawa@gmail.com>
Modify `canary.IsPrimaryReady()` and `canary.Initialize()` to return a
boolean indicating if the error is retriable. Modify the scheduler to
rollback the analysis and mark the Canary object as failed if the above
two functions or `canary.IsCanaryRead()` returns false along with an
error.
Signed-off-by: Sanskar Jaiswal <jaiswalsanskar078@gmail.com>
This adds a new Checksum field to the canary webhook body, which is a
hash of the LastAppliedSpec and TrackedConfigs.
This can be used to identify the rollout of a specific configuration,
and differentiate between webhooks being sent for different
configuration and deployment versions.
Signed-off-by: Kevin McDermott <kevin@weave.works>
Suspend, if set to true will suspend the Canary, disabling any canary runs
regardless of any changes to its target, services, etc. Note that if the
Canary is suspended during an analysis, its paused until the Canary is unsuspended.
Signed-off-by: Sanskar Jaiswal <jaiswalsanskar078@gmail.com>
Run the `confirm-rollout` webhook check right before scaling up the
deployment only, instead of running it on every loop.
Signed-off-by: Sanskar Jaiswal <jaiswalsanskar078@gmail.com>
Prevents the canary from getting triggered, when a canary deploy is
updated to match the primary deploy after an analysis fails.
Signed-off-by: Sanskar Jaiswal <sanskar.jaiswal@weave.works>
Sanskar Jaiswal
Pedram Pourmohammad
Vishal Kumar Singh
Steven Davidovitz
cappyzawa
Stefan Prodan
Thomas Banksandlnx01
Kevin McDermott
miguelvalerio
ta924@yahoo.com
Sanskar Jaiswal
Ying Liu
Olivier Michaelis
Jason Blackburn
Mayank Shah
robq99
Daniel Albuquerque
Forrest Thomas
Sebastien Le Digabel
mathetake
Tariq Ibrahim
sayboras