[
https://issues.apache.org/jira/browse/FLINK-40119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated FLINK-40119:
-----------------------------------
Labels: pull-request-available (was: )
> Blue/Green: after an aborted transition, the next deploy deletes Blue
> immediately instead of waiting the deletion delay
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: FLINK-40119
> URL: https://issues.apache.org/jira/browse/FLINK-40119
> Project: Flink
> Issue Type: Bug
> Components: Kubernetes Operator
> Affects Versions: kubernetes-operator-1.15.0
> Reporter: Calico Shop
> Priority: Major
> Labels: pull-request-available
>
> When a Blue/Green transition is aborted, the deployment rolls back to
> ACTIVE_BLUE but `deploymentReadyTimestamp` is not cleared - it keeps the
> value from the aborted transition.
> On the next deployment, the delete-Blue gate computes `deletionTimestamp =
> deploymentReadyTimestamp + deletionDelay`. Because the timestamp is stale
> (from the previous transition), this value is already in the past, so Blue is
> deleted the instant Green first reports RUNNING 0 skipping the deletion delay
> entirely.
> Steps to reproduce:
> 1. Deploy a Blue/Green deployment (ACTIVE_BLUE).
> 2. Trigger a transition to Green and let Green be marked ready (sets
> `deploymentReadyTimestamp`).
> 3. Cause the transition to abort (rolls back to ACTIVE_BLUE).
> 4. Trigger another deployment.
> 5. Observe Blue is deleted immediately once Green reports RUNNING, without
> honoring the deletion delay.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
