[
https://issues.apache.org/jira/browse/FLINK-40119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gyula Fora closed FLINK-40119.
------------------------------
Fix Version/s: kubernetes-operator-1.16.0
Resolution: Fixed
Merged to main 16280db8e33df55dad4577935a0cd5a76602eba1
> 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
> Fix For: kubernetes-operator-1.16.0
>
>
> 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)
