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
