1996fanrui commented on code in PR #677: URL: https://github.com/apache/flink-kubernetes-operator/pull/677#discussion_r1328450023
########## flink-autoscaler/src/main/java/org/apache/flink/autoscaler/state/AutoScalerStateStore.java: ########## @@ -0,0 +1,58 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.flink.autoscaler.state; + +import org.apache.flink.annotation.Experimental; +import org.apache.flink.autoscaler.JobAutoScalerContext; + +/** + * The state store is responsible for store all states during scaling. + * + * @param <KEY> The job key. + * @param <Context> Instance of JobAutoScalerContext. + */ +@Experimental +public interface AutoScalerStateStore<KEY, Context extends JobAutoScalerContext<KEY>> { + + void storeScalingHistory(Context jobContext, String scalingHistory); Review Comment: > improvement1 The improvement1 sounds make sense to me, and I need to improve the `SerializableState`. The current `deserialize` method needs to create a object first, and then call `object.deserialize(serializedResult)`. In general, the serialize is a separate object. I'm afraid whether it's too complex If we introduce 2 class for each state. > improvement2 For improvement2, my concern is the serialized type is changed, and all old jobs cannot be compatible directly. The compatibility of `byte[]` must be stronger than String, but the benefits it brings are uncertain (because there may not be classes that can only be serialized into `byte[]` in the future). The negative impact is certain, and it will bring additional migration costs to historical users. ########## flink-autoscaler/src/main/java/org/apache/flink/autoscaler/state/AutoScalerStateStore.java: ########## @@ -0,0 +1,58 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ + +package org.apache.flink.autoscaler.state; + +import org.apache.flink.annotation.Experimental; +import org.apache.flink.autoscaler.JobAutoScalerContext; + +/** + * The state store is responsible for store all states during scaling. + * + * @param <KEY> The job key. + * @param <Context> Instance of JobAutoScalerContext. + */ +@Experimental +public interface AutoScalerStateStore<KEY, Context extends JobAutoScalerContext<KEY>> { + + void storeScalingHistory(Context jobContext, String scalingHistory); Review Comment: Hi @gyfora @mxm , because of some offline comments and ease of review, I split the decoupling into the FLINK-33097 and FLINK-33098. Of course, if you think they should be merged to one PR. I will go ahead at this PR with multiple commits. @Samrat002 provided 2 improvements about the `StateStore`. ## 1. Using the structured class instead of `String` The structured class is clearer than String. First of all, we define the `SerializableState` interface to abstract the `serialize` and `deserialize`. ``` interface SerializableState<State extends SerializableState> { String serialize(); State deserialize(String serializedResult); } ``` And then, define a `ScalingHistory` class, it implement the `SerializableState`. ## 2. Using the `byte[]` instead of `String` as the serialized result Reason: In the future there may be some complex state objects that cannot be serialized to String. Hi @Samrat002 , please correct me if my description is wrong, thanks~ -- 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]
