Using a separate CR for managing the savepoints is really a good idea.
After then managing savepoints will be easier and we will not leak any
unusable savepoints on the object storage.
Best,
Yang
On Wed, Mar 13, 2024 at 4:40 AM Gyula Fóra wrote:
> That would be great Mate! If you could draw up
That would be great Mate! If you could draw up a FLIP for this that would
be nice as this is a rather large change that will have a significant
impact for existing users.
If possible it would be good to provide some backward compatibility /
transition period while we preserve the current content o
Hi,
I really like this idea as well, I think it would be a great improvement
compared to how manual savepoints currently work, and suits Kubernetes
workflows a lot better.
If there are no objections, I can investigate it during the next few weeks
and see how this could be implemented in the curre
That's definitely a good improvement Robert and we should add it at some
point. At the point in time when this was implemented we went with the
current simpler / more lightweight approach.
However if anyone is interested in working on this / contributing this
improvement I would personally support
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 repo
I agree that we could start with the annotation approach and collect the
feedback at the same time.
Best,
Yang
Őrhidi Mátyás 于2022年3月2日周三 20:06写道：
> Thank you for your feedback!
>
> The annotation on the
>
> @ControllerConfiguration(generationAwareEventProcessing = false)
> FlinkDeploymentContr
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
manua
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 于2022年3月2日周三 16:29写道：
> Thanks Matyas,
>
> From a user perspective I think the annotation is pretty nice and user
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 ha
