Malthe
07/16/2025, 6:18 AMAlex Kennedy
07/17/2025, 12:17 AMownerReference on Pods are being set to an unrelated Deployment (as opposed to the FlinkDeployment who is the real owner controlling the pods' creation). This ends up creating unexpected results in downstream metrics (investigation here). I think ArgoCD does a good job of illistrating the ownerReference relationships for visual learners.
apiVersion: v1
kind: Pod
metadata:
labels:
app: apache-feed-job-notifications
<http://app.kubernetes.io/instance|app.kubernetes.io/instance>: nis-apache-feed-app
<http://app.kubernetes.io/name|app.kubernetes.io/name>: apache-flink-feed-job
component: taskmanager
<http://helm.sh/chart|helm.sh/chart>: apache-flink-feed-job-0.0.3
type: flink-native-kubernetes
name: apache-feed-job-notifications-taskmanager-5-39
namespace: nis
ownerReferences:
- apiVersion: apps/v1
blockOwnerDeletion: true
controller: true
kind: Deployment
name: apache-feed-job-notifications
spec:
{...}
I am waiting on a JIRA account to file an issue but thought I would at least start a discussion here to get the community's appetite for aligning these pods' ownerRefernce to be more consistent with k8s best practices(?). I am a bit new to all the intrecicies of ownerReference so maybe there is some part I am missing here but at minimum the current behavior seems strange that a 3rd party controller is setting an ownerReference to a different k8s kind outside of it's domain, no?Daren Wong
07/18/2025, 8:43 AMVikas Patil
07/19/2025, 7:58 PMjava21 docker image for flink 1.19.X or 1.20.X ?RocMarshal
07/24/2025, 2:14 AMVictor Babenko
07/28/2025, 8:10 PMPoorvank Bhatia
07/29/2025, 8:14 AMRosa Seohwa Kang
07/29/2025, 7:28 PMRocMarshal
07/31/2025, 9:10 AMVinod Sherikar
08/05/2025, 6:03 AMRocMarshal
08/06/2025, 11:08 AMJakub Stejskal
08/07/2025, 9:14 AMRocMarshal
08/11/2025, 9:20 AMPeter Huang
08/20/2025, 11:53 PMMarco Scalerandi
08/23/2025, 5:35 PMJakub Stejskal
08/28/2025, 4:35 PMRyan van Huuksloot
09/02/2025, 5:55 PMNicholas Erasmus
09/05/2025, 8:46 AMThomas Cooper
09/16/2025, 2:24 PMTamir Sagi
09/16/2025, 4:45 PMDiljeet Singh
09/23/2025, 4:32 PMLuca Occhipinti
09/25/2025, 8:55 AMHang Ruan
09/26/2025, 8:29 AMRosa Seohwa Kang
10/14/2025, 12:05 PMBarak Ben-Nathan
10/19/2025, 7:24 AMJohn Watson
10/20/2025, 1:26 PMK Nunes
10/28/2025, 12:16 PMDeltaSinkInternal implements Sink<IN> and has these methods:
public Optional<Committer<T>> createCommitter() throws IOException
public Optional<SimpleVersionedSerializer<T>> getCommittableSerializer()
The framework discovers and invokes createWriter() perfectly, but createCommitter() is never called. When I tried adding @Override, I got a compilation error saying these methods aren't part of the Sink<IN> interface.
The Question:
How does a Sink expose its Committer in Flink 2.0? Is there a marker interface I'm missing? How does FileSink do it?
I suspect there's a specific pattern or interface (maybe something that replaced TwoPhaseCommittingSink from 1.x) that I need to implement, but I can't find documentation about it.
Related:
• Delta Lake issue: https://github.com/delta-io/delta/issues/5228
• My implementation branch: https://github.com/kdsnunes/delta/tree/flink/add-flink-2.0-support
• (I'm also trying to get access to Flink's Jira to create an issue there, but it's pending approval)
Any pointers would be super appreciated! Has anyone migrated a connector with Committer support to 2.0?
Thanks in advance! 🙏Alex Nitavsky
10/28/2025, 12:38 PMpranav tiwari
10/31/2025, 12:37 AMHang Ruan
10/31/2025, 9:33 AM