gyfora commented on code in PR #685: URL: https://github.com/apache/flink-kubernetes-operator/pull/685#discussion_r1368147631
########## flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/autoscaler/KubernetesAutoScalerEventHandler.java: ########## @@ -43,26 +52,71 @@ public void handleEvent( String reason, String message, @Nullable String messageKey, - @Nullable Duration interval) { - if (interval == null) { - eventRecorder.triggerEvent( - context.getResource(), - EventRecorder.Type.valueOf(type.name()), - reason, - message, - EventRecorder.Component.Operator, - messageKey, - context.getKubernetesClient()); + @Nonnull Duration interval) { + eventRecorder.triggerEvent( + context.getResource(), + EventRecorder.Type.valueOf(type.name()), + reason, + message, + EventRecorder.Component.Operator, + messageKey, + context.getKubernetesClient()); + } + + @Override + public void handleScalingEvent( + KubernetesJobAutoScalerContext context, + Map<JobVertexID, ScalingSummary> scalingSummaries, + boolean scaled, + @Nonnull Duration interval) { + if (scaled) { + AutoScalerEventHandler.super.handleScalingEvent( + context, scalingSummaries, scaled, interval); } else { - eventRecorder.triggerEventByInterval( + var conf = context.getConfiguration(); + var scalingReport = AutoScalerEventHandler.scalingReport(scalingSummaries, scaled); + var labels = Map.of(PARALLELISM_MAP_KEY, getParallelismHashCode(scalingSummaries)); Review Comment: @1996fanrui The problem with your approach is that it breaks the messageKey logic for scaling events (you set a new key every time the parallelism changes but only when scaling is off) The general problem with the current interface is that it already contains many Kubernetes specific parts (messageKey) but not enough to properly implement new functionality (such as the one we are trying here to deduplicate events based on certain logic, like the actual parallelism overrides) In other interfaces like the StateStore we decided to go with specific methods, and I think that's what we should do here as well. I prefer @clarax s solution as it allows us complete flexibility in the Kubernetes implementation without pushing anything on to the interface. To give a bit more background on the `messageKey` , we use that to define the specific event when triggering in Kubernetes such that we keep the history (last triggered, etc) without always creating new event objects. This is completely independent of the interval / parallelism based triggering that are trying to do 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: issues-unsubscr...@flink.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org