Have you guys considered making savepoints a first class citizen in the Kubernetes operator? E.g. to trigger a savepoint, you create a "FlinkSavepoint" CR, the K8s operator picks up that resource and tries to create a savepoint indefinitely until the savepoint has been successfully created. We report the savepoint status and location in the "status" field.
We could even add an (optional) finalizer to delete the physical savepoint from the savepoint storage once the "FlinkSavepoint" CR has been deleted. optional: the savepoint spec could contain a field "retain physical savepoint" or something, that controls the delete behavior. On Thu, Mar 3, 2022 at 4:02 AM Yang Wang <danrtsey...@gmail.com> wrote: > I agree that we could start with the annotation approach and collect the > feedback at the same time. > > Best, > Yang > > Őrhidi Mátyás <matyas.orh...@gmail.com> 于2022年3月2日周三 20:06写道： > > > Thank you for your feedback! > > > > The annotation on the > > > > @ControllerConfiguration(generationAwareEventProcessing = false) > > FlinkDeploymentController > > > > already enables the event triggering based on metadata changes. It was > set > > earlier to support some failure scenarios. (It can be used for example to > > manually reenable the reconcile loop when it got stuck in an error phase) > > > > I will go ahead and propose a PR using annotations then. > > > > Cheers, > > Matyas > > > > On Wed, Mar 2, 2022 at 12:47 PM Yang Wang <danrtsey...@gmail.com> wrote: > > > > > I also like the annotation approach since it is more natural. > > > But I am not sure about whether the meta data change will trigger an > > event > > > in java-operator-sdk. > > > > > > > > > Best, > > > Yang > > > > > > Gyula Fóra <gyula.f...@gmail.com> 于2022年3月2日周三 16:29写道： > > > > > > > Thanks Matyas, > > > > > > > > From a user perspective I think the annotation is pretty nice and > user > > > > friendly so I personally prefer that approach. > > > > > > > > You said: > > > > "It seems, the java-operator-sdk handles the changes of the > .metadata > > > and > > > > .spec fields of custom resources differently." > > > > > > > > What implications does this have on the above mentioned 2 approaches? > > > Does > > > > it make one more difficult than the other? > > > > > > > > Cheers > > > > Gyula > > > > > > > > > > > > > > > > On Tue, Mar 1, 2022 at 1:52 PM Őrhidi Mátyás < > matyas.orh...@gmail.com> > > > > wrote: > > > > > > > > > Hi All! > > > > > > > > > > I'd like to start a quick discussion about the way we allow users > to > > > > > trigger savepoints manually in the operator [FLINK-26181] > > > > > <https://issues.apache.org/jira/browse/FLINK-26181>. There are > > > existing > > > > > solutions already for this functionality in other operators, for > > > example: > > > > > - counter based > > > > > < > > > > > > > > > > > > > > > https://github.com/spotify/flink-on-k8s-operator/blob/master/docs/savepoints_guide.md#2-taking-savepoints-by-updating-the-flinkcluster-custom-resource > > > > > > > > > > > - annotation based > > > > > < > > > > > > > > > > > > > > > https://github.com/spotify/flink-on-k8s-operator/blob/master/docs/savepoints_guide.md#3-taking-savepoints-by-attaching-annotation-to-the-flinkcluster-custom-resource > > > > > > > > > > > > > > > > We could implement any of these or both or come up with our own > > > approach. > > > > > It seems, the java-operator-sdk handles the changes of the > .metadata > > > and > > > > > .spec fields of custom resources differently. For further info see > > the > > > > > chapter Generation Awareness and Event Filtering in the docs > > > > > <https://javaoperatorsdk.io/docs/features>. > > > > > > > > > > Let me know what you think. > > > > > > > > > > Cheers, > > > > > Matyas > > > > > > > > > > > > > > >
