apache/flink/tree/master/flink-kubernetes
Regards,
Alexis.
From: Gyula Fóra mailto:gyula.f...@gmail.com>>
Sent: Montag, 17. Januar 2022 12:40
To: dev mailto:dev@flink.apache.org>>
Cc: Xintong Song mailto:tonysong...@gmail.com>>; user
mailto:u...@flink.apache.org>>
n of Control
> containers such as Spring. I only used javax annotations (soon to be
> jakarta), so it’s not tied to Spring.
>
>
>
> Something I haven’t considered at all in my code is ingress for Flink’s UI.
>
>
>
> Let me know what you think.
>
>
>
> [1]
&
: Xintong Song ; user
Subject: Re: Flink native k8s integration vs. operator
Hi Yang!
Thanks for the input!
I agree with you on both points that you made. Even if we might support both
standalone and native modes in the long run, we should probably build the first
version on top of the native
Hi Yang!
Thanks for the input!
I agree with you on both points that you made. Even if we might support
both standalone and native modes in the long run, we should probably build
the first version on top of the native integration.
This I feel will result in a much simpler, minimalistic first versi
Glad to see that the interest of this thread keeps going. And thanks
Thomas, Gyula, and Marton for driving this effort.
I want to share my two cents about the Flink K8s operator.
> Standalone deployment VS native K8s integration
There is already some feature requirement issue[1] for the existin
Thanks for volunteering to drive this effort, Marton, Thomas and Gyula.
Looking forward to the public discussion. Please feel free to reach out if
there's anything you need from us.
Thank you~
Xintong Song
On Fri, Jan 14, 2022 at 8:27 AM Chenya Zhang
wrote:
> Thanks Thomas, Gyula, and Marto
Thanks Thomas, Gyula, and Marton for driving this effort! It would greatly
ease the adoption of Apache Flink on Kubernetes and help to address the
current operational pain points as mentioned. Look forward to the proposal
and more discussions!
Best,
Chenya
On Thu, Jan 13, 2022 at 12:15 PM Márton
Hi All,
I am pleased to see the level of enthusiasm and technical consideration
already emerging in this thread. I wholeheartedly support building an
operator and endorsing it via placing it under the Apache Flink umbrella
(as a separate repository) as the current lack of it is clearly becoming an
Hi Thomas,
Yes, I was referring to a separate repository under Apache Flink.
Cheers,
Konstantin
On Thu, Jan 13, 2022 at 6:19 AM Thomas Weise wrote:
> Hi everyone,
>
> Thanks for the feedback and discussion. A few additional thoughts:
>
> [Konstantin] > With respect to common lifecycle managem
Hi everyone,
Thanks for the feedback and discussion. A few additional thoughts:
[Konstantin] > With respect to common lifecycle management operations:
these features are
> not available (within Apache Flink) for any of the other resource providers
> (YARN, Standalone) either. From this perspectiv
cc dev@
Hi Thomas, Hi everyone,
Thank you for starting this discussion and sorry for chiming in late.
I agree with Thomas' and David's assessment of Flink's "Native Kubernetes
Integration", in particular, it does actually not integrate well with the
Kubernetes ecosystem despite being called "nat
11 matches
Mail list logo
