dalelane commented on code in PR #1199:
URL:
https://github.com/apache/flink-kubernetes-operator/pull/1199#discussion_r4003689899
##########
flink-kubernetes-operator/src/main/java/org/apache/flink/kubernetes/operator/reconciler/deployment/ApplicationReconciler.java:
##########
@@ -273,6 +285,24 @@ private static void
setRandomJobResultStorePath(Configuration effectiveConfig) {
}
}
+ private static void setRandomApplicationResultStorePath(Configuration
effectiveConfig) {
+ if (effectiveConfig.contains(HighAvailabilityOptions.HA_STORAGE_PATH))
{
Review Comment:
@gyfora I'm happy to do that if you're okay with the approach in the code
here
James fairly highlighted the resource leak implication of the approach I
took [on the dev@
list](https://lists.apache.org/thread/2gs2xzzmh8371rnc2993o9bvjsm4n6bd) where I
said:
> re: resource leak
> Yeah, I agree that what I'm proposing in FLINK-40467 doubles down on the
deal made in FLINK-27573, and maybe that's not a good thing. I used a random
UUID because that's what I saw setRandomJobResultStorePath do, but in hindsight
making directories anonymous makes the admin cleanup task harder as you can't
derive the deployment from a directory name to know what is safe to remove.
Perhaps the operator should record the path it generates in status - this would
let us automate cleaning up the path for previous launches?
if you want to discuss that aspect first, I'll hold off on adding to the PR.
But if you're okay with the approach, I'll add the delete on commit
--
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]
