noa-ramon opened a new pull request, #1254: URL: https://github.com/apache/flink-kubernetes-operator/pull/1254
## What is the purpose of the change When a two-deployment Blue/Green transition aborts, `BlueGreenDeploymentService#abortDeployment` suspends the new child and rolls the parent back. The next transition re-creates the child under the same name with `createOrReplace`; the existing resource keeps its status, so the `FlinkDeployment` controller resumes it instead of deploying it, and `spec.job.initialSavepointPath` (the serving deployment's fresh savepoint) is ignored. In `savepoint` mode the job resumes from the aborted child's own stop-savepoint; in `last-state` mode from the checkpoint in its leftover HA metadata. An attempt that aborted because of its state (e.g. a `StateMigrationException`) then fails the same way on every retry, and the only way out is deleting the child by hand. This change deletes the aborted child instead of suspending it, the same way a successful cutover deletes the outgoing deployment. See [FLINK-41404](https://issues.apache.org/jira/browse/FLINK-41404). ## Brief change log - `BlueGreenDeploymentService#abortDeployment`: when two deployments exist, the aborted one is deleted (via `ApplicationReconciler#cleanupInternal`, which cancels the job and removes its HA metadata) and the parent returns to the previous `ACTIVE_*` state. The next transition creates a fresh resource that honours `initialSavepointPath`. - An abort of the *first* deployment, where there is no other deployment to fall back to, keeps the current suspend behaviour. - Trade-off: the aborted deployment's pods are no longer kept for inspection. The parent still records the reason in `status.error` and the operator logs the abort. ## Verifying this change This change added tests and can be verified as follows: - New `FlinkBlueGreenDeploymentControllerTest#verifyRetryAfterAbortRestoresTheServingColoursFreshSavepoint`: aborts a `savepoint`-mode transition on the grace period, then retries. It asserts that only the previous deployment remains after the abort, and that the retried child is a new resource (different `metadata.uid`) whose `initialSavepointPath` is the retry's fresh savepoint. Without the fix the retried child is the aborted resource updated in place (same `uid`), and the test fails. - Two existing tests (`verifyFailureDuringTransition`, `verifyReadyTimestampResetOnAbortPreventsPrematureBlueDelete`) asserted the suspended child; they now assert that only the previous deployment remains and keeps running. - All Blue/Green test suites pass (`mvn -pl flink-kubernetes-operator test -Dtest='*BlueGreen*'`, 131 tests). - Manually verified on a cluster in both `last-state` and `savepoint` mode: after an abort, the retry starts from the serving deployment's savepoint. ## Does this pull request potentially affect one of the following parts: - Dependencies (does it add or upgrade a dependency): no - The public API, i.e., is any changes to the `CustomResourceDescriptors`: no - Core observer or reconciler logic that is regularly executed: yes, the Blue/Green abort path (not the per-reconcile hot path) ## Documentation - Does this pull request introduce a new feature? no - If yes, how is the feature documented? not applicable --- ##### Was generative AI tooling used to co-author this PR? - [X] Yes (Claude Code) Generated-by: Claude Code (Fable 5.1) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
