tillrohrmann commented on a change in pull request #13644:
URL: https://github.com/apache/flink/pull/13644#discussion_r510976264
##########
File path:
flink-kubernetes/src/main/java/org/apache/flink/kubernetes/kubeclient/FlinkKubeClient.java
##########
@@ -104,6 +106,67 @@ KubernetesWatch watchPodsAndDoCallback(
Map<String, String> labels,
WatchCallbackHandler<KubernetesPod> podCallbackHandler);
+ /**
+ * Create the ConfigMap with specified content. If the ConfigMap
already exists, a FlinkRuntimeException will be
+ * thrown.
+ *
+ * @param configMap ConfigMap.
+ *
+ * @return Return the ConfigMap create future.
+ */
+ CompletableFuture<Void> createConfigMap(KubernetesConfigMap configMap);
+
+ /**
+ * Get the ConfigMap with specified name.
+ *
+ * @param name ConfigMap name.
+ *
+ * @return Return the ConfigMap, or empty if the ConfigMap does not
exist.
+ */
+ Optional<KubernetesConfigMap> getConfigMap(String name);
+
+ /**
+ * Update an existing ConfigMap with the data. Benefit from <a
href=https://kubernetes.io/docs/reference/using-api/api-concepts/#resource-versions>
+ * resource version</a> and combined with {@link
#getConfigMap(String)}, we could perform a get-check-and-update
+ * transactional operation. Since concurrent modification could happen
on a same ConfigMap,
+ * the update operation may fail. We need to retry internally. The max
retry attempts could be
+ * configured via {@link
org.apache.flink.kubernetes.configuration.KubernetesConfigOptions#KUBERNETES_TRANSACTIONAL_OPERATION_MAX_RETRIES}.
+ *
+ * @param configMapName ConfigMap to be replaced with.
+ * @param function Function to be applied to the obtained
ConfigMap and get a new updated one. If the returned
Review comment:
Hmm, how would this pattern work with concurrent modifications? Assume
that the following happens: We get the `configMap`, discard the `stateHandle`
and then return the updated `configMap` w/o the state handle key. Now for some
reason `internalClient.createOrReplace` fails and the whole operation will be
retried. Now when the `function` is re-executed it will fail right away because
`stateHandle` can no longer be discarded but it is still in the `configMap`
(because the update failed).
I guess what I want to say is that we should not discard state which has not
been removed from the `configMap`. Hence, it would be good if we could support
an API where we first update the `configMap` and only do an operation if the
update has succeeded.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
