[
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:41 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}} like
[these|https://github.com/apache/flink-kubernetes-operator/blob/a1842d4c0170feb008293963ec51c0343f42771d/flink-kubernetes-standalone/pom.xml#L74-L79]
(not provided by {{flink-kubernetes}}), so their package name will stick with
{{io.fabric8}} and lead to compilation failure.
2 work arounds I can think of
# to have a dedicated subproject just to relocate back the {{io.fabric8}}
classes in {{flink-kubernetes}}, (or other way around relocate things to
{{org.apache.flink.kubernetes.shaded.io.fabric8}}) which seems a little bit
ugly.
# ignore the {{io.fabric8}} classes from {{flink-kubernetes}} and add all
required {{io.fabric8}} dependencies to pom.xml , however it seems
{{flink-kubernetes}} (5.12.3) vs {{flink-kubernetes-operator}} (6.2.0) are
using different {{io.fabric8}} versions, not sure if it is ok to upgrade all
dependencies version to 6.2.0.
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 arguments. The tricky
thing is: there are certain {{io.fabric8}} classes in
{{flink-kubernetes-operator}} like
[these|https://github.com/apache/flink-kubernetes-operator/blob/a1842d4c0170feb008293963ec51c0343f42771d/flink-kubernetes-standalone/pom.xml#L74-L79]
(not provided by {{{}flink-kubernetes{}}}), so their package name will stick
with {{io.fabric8}} and lead to compilation failure.
2 work arounds I can think of
# to have a dedicated subproject just to relocate back the {{io.fabric8}}
classes in {{{}flink-kubernetes{}}}, (or other way around relocate things to
{{{}org.apache.flink.kubernetes.shaded.io.fabric8{}}}) which seems a little bit
ugly.
# ignore the {{io.fabric8 }}classes from{{ }}{{flink-kubernetes }}and add all
required{{ }}{{io.fabric8 }}dependencies to pom.xml , however it seems
{{flink-kubernetes }} (5.12.3) vs {{flink-kubernetes-operator}} (6.2.0) are
using different {{io.fabric8}} versions, not sure if it is ok to upgrade all
dependencies version to 6.2.0.{{ }}{{{}{}}}{{{}{}}}
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)
