[
https://issues.apache.org/jira/browse/FLINK-41074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated FLINK-41074:
-----------------------------------
Labels: pull-request-available (was: )
> Blue/green deployment can retire the active deployment using readiness from
> an older candidate revision
> -------------------------------------------------------------------------------------------------------
>
> Key: FLINK-41074
> URL: https://issues.apache.org/jira/browse/FLINK-41074
> Project: Flink
> Issue Type: Bug
> Components: Kubernetes Operator
> Reporter: Luca Castelli
> Priority: Minor
> Labels: pull-request-available
>
> Updating a FlinkBlueGreenDeployment during an ongoing transition can change
> Green’s spec while its deletion delay is running. Two related bugs can then
> cause premature retirement of Blue:
> # Stale readiness: Green is considered ready based on RUNNING/STABLE status
> even when status.observedGeneration is behind metadata.generation.
> # Inherited deletion delay: Once the updated Green revision becomes ready,
> it reuses the previous revision’s deploymentReadyTimestamp instead of
> receiving a fresh deletion delay.
>
> *Reproduction*
> # Deploy Blue, then update the parent to initiate Green.
> # Wait until Green is ready and the configured deletion delay starts.
> # Update the parent again, for example by changing job parallelism.
> # Observe that Blue can retire either:
> *
> ** while Green’s new generation remains unobserved, or
> ** before a full deletion delay has elapsed for the newly ready generation.
>
> *Expected behavior*
> Require readiness for Green’s current desired generation and bind the
> deletion-delay timestamp to that generation. Relevant candidate updates or
> observed readiness loss should invalidate previous readiness evidence.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
