Makes sense, Thanks for the clarification. Best Regards Ahmed Hamdy
On Thu, 14 Sept 2023 at 14:07, Gyula Fóra <gyula.f...@gmail.com> wrote: > Hi Ahmed! > > As I mentioned in the first email, the Flink Operator explicitly aims to > make running Flink and Flink Platforms on Kubernetes easy. As most users > are platform teams supporting Flink inside a company or running a service > it's basically always required to support several Flink versions at the > same time. > > Enterprise users are in many cases using Flink versions that are older than > the last 2 minor releases (currently supported by the community). However > the operator itself is somewhat independent of Flink itself, and most > operator features work across several Flink versions at the same time. > > Based on this it's relatively easy for us to support deploying to previous > Flink minor versions (within some reasonable limit). This means that as > long as platform teams keep the operator up-to-date they get the latest > stability / deployment improvements but can still provide compatibility for > their users for older Flink job versions. > > Cheers, > Gyula > > On Thu, Sep 14, 2023 at 2:59 PM Ahmed Hamdy <hamdy10...@gmail.com> wrote: > > > Thanks Gyula, > > +1 for the proposal in general. > > May I ask why are we interested in supporting more than the ones > supported > > by the community? > > for example I understand all versions prior to 1.16 are now out of > support, > > why should we tie our compatibility 4 versions behind? > > Best Regards > > Ahmed Hamdy > > > > > > On Thu, 14 Sept 2023 at 12:18, ConradJam <jam.gz...@gmail.com> wrote: > > > > > +1 > > > > > > Yang Wang <wangyang0...@apache.org> 于2023年9月14日周四 16:15写道： > > > > > > > Since the users could always use the old Flink Kubernetes Operator > > > version > > > > along with old Flink versions, I am totally in favor of this proposal > > to > > > > reduce maintenance burden. > > > > > > > > Best, > > > > Yang > > > > > > > > Biao Geng <biaoge...@gmail.com> 于2023年9月6日周三 18:15写道： > > > > > > > > > +1 for the proposal. > > > > > > > > > > Best, > > > > > Biao Geng > > > > > > > > > > Gyula Fóra <gyula.f...@gmail.com> 于2023年9月6日周三 16:10写道： > > > > > > > > > > > @Zhanghao Chen: > > > > > > > > > > > > I am not completely sure at this point what this will mean for > 2.0 > > > > simply > > > > > > because I am also not sure what that will mean for the operator > as > > > well > > > > > :) > > > > > > I think this will depend on the compatibility guarantees we can > > > provide > > > > > > across Flink major versions in general. We have to look into that > > and > > > > > > tackle the question there independently. > > > > > > > > > > > > Gyula > > > > > > > > > > > > On Tue, Sep 5, 2023 at 6:12 PM Maximilian Michels < > m...@apache.org> > > > > > wrote: > > > > > > > > > > > > > +1 Sounds good! Four releases give a decent amount of time to > > > migrate > > > > > > > to the next Flink version. > > > > > > > > > > > > > > On Tue, Sep 5, 2023 at 5:33 PM Őrhidi Mátyás < > > > > matyas.orh...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > On Tue, Sep 5, 2023 at 8:03 AM Thomas Weise <t...@apache.org> > > > > wrote: > > > > > > > > > > > > > > > > > +1, thanks for the proposal > > > > > > > > > > > > > > > > > > On Tue, Sep 5, 2023 at 8:13 AM Gyula Fóra < > > > gyula.f...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hi All! > > > > > > > > > > > > > > > > > > > > @Maximilian Michels <m...@apache.org> has raised the > > question > > > > of > > > > > > > Flink > > > > > > > > > > version support in the operator before the last release. > I > > > > would > > > > > > > like to > > > > > > > > > > open this discussion publicly so we can finalize this > > before > > > > the > > > > > > next > > > > > > > > > > release. > > > > > > > > > > > > > > > > > > > > Background: > > > > > > > > > > Currently the Flink Operator supports all Flink versions > > > since > > > > > > Flink > > > > > > > > > 1.13. > > > > > > > > > > While this is great for the users, it introduces a lot of > > > > > backward > > > > > > > > > > compatibility related code in the operator logic and also > > > adds > > > > > > > > > considerable > > > > > > > > > > time to the CI. We should strike a reasonable balance > here > > > that > > > > > > > allows us > > > > > > > > > > to move forward and eliminate some of this tech debt. > > > > > > > > > > > > > > > > > > > > In the current model it is also impossible to support all > > > > > features > > > > > > > for > > > > > > > > > all > > > > > > > > > > Flink versions which leads to some confusion over time. > > > > > > > > > > > > > > > > > > > > Proposal: > > > > > > > > > > Since it's a key feature of the kubernetes operator to > > > support > > > > > > > several > > > > > > > > > > versions at the same time, I propose to support the last > 4 > > > > stable > > > > > > > Flink > > > > > > > > > > minor versions. Currently this would mean to support > Flink > > > > > > 1.14-1.17 > > > > > > > (and > > > > > > > > > > drop 1.13 support). When Flink 1.18 is released we would > > drop > > > > > 1.14 > > > > > > > > > support > > > > > > > > > > and so on. Given the Flink release cadence this means > > about 2 > > > > > year > > > > > > > > > support > > > > > > > > > > for each Flink version. > > > > > > > > > > > > > > > > > > > > What do you think? > > > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > Gyula > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
