Zhangyx39 commented on code in PR #1161:
URL:
https://github.com/apache/flink-kubernetes-operator/pull/1161#discussion_r3583355989
##########
flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/controller/bluegreen/BlueGreenDeploymentService.java:
##########
@@ -476,6 +476,20 @@ public UpdateControl<FlinkBlueGreenDeployment>
monitorTransition(
TransitionState transitionState =
determineTransitionState(context,
currentBlueGreenDeploymentType);
+ CutoverSchedule schedule =
+ new CutoverSchedule(
+ instantStrToMillis(
+
context.getDeploymentStatus().getDeploymentReadyTimestamp()),
+ BlueGreenUtils.getDeploymentDeletionDelay(context));
+
+ // If an earlier BlueGreenDeployment deleted the previous deployment
but failed before
+ // finalizing the transition, there is nothing to roll back to so we
must finalize forward
+ // instead of aborting to a deleted target.
+ if (isGoneOrTerminating(transitionState.currentDeployment)
Review Comment:
Thank you for putting together this follow-up. This is a clean, schema-free
way to close the important crash/status-patch gap after #1154. One question
about the remaining read-after-write window: transitionState.currentDeployment
comes from the JOSDK secondary-resource informer cache. If deletion was
accepted but the ACTIVE status patch failed, a reconcile could still see cached
Blue without deletionTimestamp; if Green is not ready and the abort deadline
has expired, we could still reach shouldWeAbort(). Would it make sense to
perform a live GET of the previous FlinkDeployment only at that destructive
abort boundary (ready timestamp recorded and deletion/abort deadlines passed),
finalizing forward if the API reports it absent or terminating? If the GET
fails, we could reschedule rather than abort. This should add negligible API
load because it is limited to a rare recovery path. A test with stale cached
Blue while the API reports it terminating would also be valuable. Really appr
eciate the thoughtful fix here.
--
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]
