[
https://issues.apache.org/jira/browse/FLINK-29634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653483#comment-17653483
]
Jiale Tan edited comment on FLINK-29634 at 1/2/23 2:20 AM:
-----------------------------------------------------------
[~gyfora] [~thw] Thanks for the guidance!
I am trying to bump {{flink.version}} up to 1.17 (SNAPSHOT) locally to take
advantage of the checkpoint rest API classes in 1.17 and start coding. However
I found it a little bit tricky to deal with the dependencies, since in flink
1.17 {{io.fabric8}} classes are shaded and relocated in the
{{flink-kubernetes}} in
[this|https://github.com/apache/flink/commit/17d7c39bb2a9fcbaac1ead42073c099a52171d7d]
commit.
This change will also cause {{flink-kubernetes-operator}} functions with
arguments of {{io.fabric8}} classes now requiring
{{org.apache.flink.kubernetes.shaded.io.fabric8}} classes arguments. The tricky
thing is: there are certain {{io.fabric8}} classes in
{{flink-kubernetes-operator }}which are not provided by{{ flink-kubernetes}}
like
[these,|https://github.com/apache/flink-kubernetes-operator/blob/a1842d4c0170feb008293963ec51c0343f42771d/flink-kubernetes-standalone/pom.xml#L74-L79]
so their package name will stick with {{io.fabric8 and lead to compilation
failure.}}
One work around I can think of is to have a dedicated subproject just to
relocate back the {{io.fabric8}} classes in {{{}flink-kubernetes{}}}, which
seems a little bit ugly.
I am wondering if you folks have some good practices to deal with this.
was (Author: JIRAUSER290356):
[~gyfora] [~thw] Thanks for the guidance!
I am trying to bump {{flink.version}} up to 1.17 (SNAPSHOT) locally to take
advantage of the checkpoint rest API classes in 1.17 and start coding. However
I found it a little bit tricky to deal with the dependencies, since in flink
1.17 {{io.fabric8}} classes are shaded and relocated in the
{{flink-kubernetes}} in
[this|https://github.com/apache/flink/commit/17d7c39bb2a9fcbaac1ead42073c099a52171d7d]
commit.
This change will also cause {{flink-kubernetes-operator}} functions with
arguments of {{io.fabric8}} classes now requiring
{{org.apache.flink.kubernetes.shaded.io.fabric8}} classes. The tricky thing is:
there are certain {{io.fabric8}} classes in {{flink-kubernetes-operator which
are not provided by flink-kubernetes}} like
[these,|https://github.com/apache/flink-kubernetes-operator/blob/a1842d4c0170feb008293963ec51c0343f42771d/flink-kubernetes-standalone/pom.xml#L74-L79]
so their package name will stick with {{io.fabric8 and lead to compilation
failure.}}
One work around I can think of is to have a dedicated subproject just to
relocate back the {{io.fabric8}} classes in {{{}flink-kubernetes{}}}, which
seems a little bit ugly.
I am wondering if you folks have some good practices to deal with this.
> Support periodic checkpoint triggering
> --------------------------------------
>
> Key: FLINK-29634
> URL: https://issues.apache.org/jira/browse/FLINK-29634
> Project: Flink
> Issue Type: New Feature
> Components: Kubernetes Operator
> Reporter: Thomas Weise
> Assignee: Jiale Tan
> Priority: Major
>
> Similar to the support for periodic savepoints, the operator should support
> triggering periodic checkpoints to break the incremental checkpoint chain.
> Support for external triggering will come with 1.17:
> https://issues.apache.org/jira/browse/FLINK-27101
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
