You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by Gyula Fóra <gy...@apache.org> on 2022/04/25 18:22:08 UTC
[DISCUSS] Next Flink Kubernetes Operator release timeline
Hi Devs!
The community has been working hard on cleaning up the operator logic and
adding some core features that have been missing from the preview release
(session jobs for example). We have also added some significant
improvements around deployment/operations.
With the current pace of the development I think in a few weeks we should
be in a good position to release next version of the operator. This would
also give us the opportunity to add support for the upcoming 1.15 release :)
We have to decide on 2 main things:
1. Target release date
2. Release version
With the current state of the project I am confident that we could cut a
really good release candidate towards the end of May. I would suggest a
feature *freeze mid May (May 16)*, with a target *RC0 date of May 23*. If
on May 16 we feel that we are ready we could also prepare the release
candidate earlier.
As for the release version, I personally feel that this is a good time
for *version
1.0.0*.
While 1.0.0 signals a certain confidence in the stability of the current
API (compared to the preview release) I would keep the kubernetes resource
version v1beta1.
It would also be great if someone could volunteer to join me to help manage
the release process this time so I can share the knowledge gathered during
the preview release :)
Let me know what you think!
Cheers,
Gyula
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Posted by Gyula Fóra <gy...@apache.org>.
Hi Thomas!
Thank you for raising your concerns.
I agree that we should document the compatibility guarantees that we expect
to provide going forward.
Since releasing 0.1 (v1alpha1) we added a great deal of new core features.
This required some modification to the CR obviously but actually it only
touched the status subresource and the mainly user facing spec itself had
only backward compatible changes. In the future we also would like to start
moving fields out from the status to some configmaps to make it easier to
change logic in the future (this can be done in a backward compatible way).
Based on these I think it is fair to say that we expect to keep backward
compatibility going forward for the CR itself and I think release version
1.0.0 (with api version v1beta1) shows our confidence in the overall spec
and design. With the core features covered I would consider this production
ready and 1.0.0 marks it so, based on the wider experience we gain from
users we will can further improve the design towards the v1 api release (in
a backward compatible way :))
As for the upgrade docs you linked, it explains the process of upgrading
from the currently experimental v1alpha1 to the new v1beta1 release. For
this release this is the relevant process, but certainly we need to upgrade
before the next release. Also you are right that the automation is not
there, that again is definitely a blocker for the next release to ensure
backward compatibility. We have tickets already for these 2 tasks. [1][2]
Cheers
Gyula
[1] https://issues.apache.org/jira/browse/FLINK-26955
[2] https://issues.apache.org/jira/browse/FLINK-27302
On Thu, May 19, 2022 at 2:26 AM Thomas Weise <th...@apache.org> wrote:
> I think before we release 1.0, we need to define and document the
> compatibility guarantees.
>
> At the moment, the CR changes frequently and as was pointed out
> earlier, there isn't any automation to ensure changes are backward
> compatible. In addition, our documentation still refers to upgrade as
> a process that involves removing the prior CRD, which IMO needs to
> change for a 1.0 release.
>
> If we feel that we are not ready to put a compatibility guarantee in
> place, then perhaps release the next version as 0.2?
>
> Thanks,
> Thomas
>
>
> [1]
> https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-main/docs/operations/upgrade/
>
> On Mon, May 16, 2022 at 5:13 PM Aitozi <gj...@gmail.com> wrote:
> >
> > Thanks Gyula. It looks good to me. I could do a favor during the release
> > also.
> > Please feel free to ping me to help the doc, release and test work :)
> >
> > Best,
> > Aitozi
> >
> > Yang Wang <da...@gmail.com> 于2022年5月16日周一 21:57写道：
> >
> > > Thanks Gyula for sharing the progress. It is very likely we could have
> the
> > > first release candidate next Monday.
> > >
> > > Best,
> > > Yang
> > >
> > > Gyula Fóra <gy...@apache.org> 于2022年5月16日周一 20:50写道：
> > >
> > > > Hi Devs!
> > > >
> > > > We are on track for our planned 1.0.0 release timeline. There are no
> > > > outstanding blocker issues on JIRA for the release.
> > > >
> > > > There are 3 outstanding new feature PRs. They are all in pretty good
> > > shape
> > > > and should be merged within a day:
> > > > https://github.com/apache/flink-kubernetes-operator/pull/213
> > > > https://github.com/apache/flink-kubernetes-operator/pull/216
> > > > https://github.com/apache/flink-kubernetes-operator/pull/217
> > > >
> > > > As we agreed previously we should not merge any more new features for
> > > > 1.0.0 and focus our efforts on testing, bug fixes and documentation
> for
> > > > this week.
> > > >
> > > > I will cut the release branch tomorrow once these PRs are merged.
> And the
> > > > target day for the first release candidate is next Monday.
> > > >
> > > > The release managers for this release will be Yang Wang and myself.
> > > >
> > > > Cheers,
> > > > Gyula
> > > >
> > > > On Wed, Apr 27, 2022 at 11:28 AM Yang Wang <da...@gmail.com>
> > > wrote:
> > > >
> > > >> Thanks @Chesnay Schepler <ch...@apache.org> for pointing out
> this.
> > > >>
> > > >> The only public interface the flink-kubernetes-operator provides is
> the
> > > >> CRD[1]. We are trying to stabilize the CRD from v1beta1.
> > > >> If more fields are introduced to support new features(e.g.
> standalone
> > > >> mode,
> > > >> SQL jobs), they should have the default value to ensure
> compatibility.
> > > >> Currently, we do not have some tools to enforce the compatibility
> > > >> guarantees. But we have created a ticket[1] to follow this and hope
> it
> > > >> could be resolved before releasing 1.0.0.
> > > >>
> > > >> Just as you said, now is also a good time to think more about the
> > > approach
> > > >> of releases. Since flink-kubernetes-operator is much simpler than
> Flink,
> > > >> we
> > > >> could have a shorter release cycle.
> > > >> Two month for a major release(1.0, 1.1, etc.) is reasonable to me.
> And
> > > >> this
> > > >> could be shorten for the minor releases. Also we need to support at
> > > least
> > > >> the last two major versions.
> > > >>
> > > >> Maybe the standalone mode support is a big enough feature for
> version
> > > 2.0.
> > > >>
> > > >>
> > > >> [1].
> > > >>
> > > >>
> > >
> https://github.com/apache/flink-kubernetes-operator/tree/main/helm/flink-kubernetes-operator/crds
> > > >> [2]. https://issues.apache.org/jira/browse/FLINK-26955
> > > >>
> > > >>
> > > >> @Hao t Chang <ht...@us.ibm.com> We do not have regular sync up
> > > meeting
> > > >> so
> > > >> far. But I think we could schedule some sync up for the 1.0.0
> release if
> > > >> necessary. Anyone who is interested are welcome.
> > > >>
> > > >>
> > > >> Best,
> > > >> Yang
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> Hao t Chang <ht...@us.ibm.com> 于2022年4月27日周三 07:45写道：
> > > >>
> > > >> > Hi Gyula,
> > > >> >
> > > >> > Thanks for the release timeline information. I would like to
> learn the
> > > >> > gathered knowledge and volunteer as well. Will there be sync up
> > > >> > meeting/call for this collaboration ?
> > > >> >
> > > >> > From: Gyula Fóra <gy...@apache.org>
> > > >> > Date: Monday, April 25, 2022 at 11:22 AM
> > > >> > To: dev <de...@flink.apache.org>
> > > >> > Subject: [DISCUSS] Next Flink Kubernetes Operator release timeline
> > > >> > Hi Devs!
> > > >> >
> > > >> > The community has been working hard on cleaning up the operator
> logic
> > > >> and
> > > >> > adding some core features that have been missing from the preview
> > > >> release
> > > >> > (session jobs for example). We have also added some significant
> > > >> > improvements around deployment/operations.
> > > >> >
> > > >> > With the current pace of the development I think in a few weeks we
> > > >> should
> > > >> > be in a good position to release next version of the operator.
> This
> > > >> would
> > > >> > also give us the opportunity to add support for the upcoming 1.15
> > > >> release
> > > >> > :)
> > > >> >
> > > >> > We have to decide on 2 main things:
> > > >> > 1. Target release date
> > > >> > 2. Release version
> > > >> >
> > > >> > With the current state of the project I am confident that we could
> > > cut a
> > > >> > really good release candidate towards the end of May. I would
> suggest
> > > a
> > > >> > feature *freeze mid May (May 16)*, with a target *RC0 date of May
> 23*.
> > > >> If
> > > >> > on May 16 we feel that we are ready we could also prepare the
> release
> > > >> > candidate earlier.
> > > >> >
> > > >> > As for the release version, I personally feel that this is a good
> time
> > > >> > for *version
> > > >> > 1.0.0*.
> > > >> > While 1.0.0 signals a certain confidence in the stability of the
> > > current
> > > >> > API (compared to the preview release) I would keep the kubernetes
> > > >> resource
> > > >> > version v1beta1.
> > > >> >
> > > >> > It would also be great if someone could volunteer to join me to
> help
> > > >> manage
> > > >> > the release process this time so I can share the knowledge
> gathered
> > > >> during
> > > >> > the preview release :)
> > > >> >
> > > >> > Let me know what you think!
> > > >> >
> > > >> > Cheers,
> > > >> > Gyula
> > > >> >
> > > >>
> > > >
> > >
>
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Posted by Thomas Weise <th...@apache.org>.
I think before we release 1.0, we need to define and document the
compatibility guarantees.
At the moment, the CR changes frequently and as was pointed out
earlier, there isn't any automation to ensure changes are backward
compatible. In addition, our documentation still refers to upgrade as
a process that involves removing the prior CRD, which IMO needs to
change for a 1.0 release.
If we feel that we are not ready to put a compatibility guarantee in
place, then perhaps release the next version as 0.2?
Thanks,
Thomas
[1] https://nightlies.apache.org/flink/flink-kubernetes-operator-docs-main/docs/operations/upgrade/
On Mon, May 16, 2022 at 5:13 PM Aitozi <gj...@gmail.com> wrote:
>
> Thanks Gyula. It looks good to me. I could do a favor during the release
> also.
> Please feel free to ping me to help the doc, release and test work :)
>
> Best,
> Aitozi
>
> Yang Wang <da...@gmail.com> 于2022年5月16日周一 21:57写道：
>
> > Thanks Gyula for sharing the progress. It is very likely we could have the
> > first release candidate next Monday.
> >
> > Best,
> > Yang
> >
> > Gyula Fóra <gy...@apache.org> 于2022年5月16日周一 20:50写道：
> >
> > > Hi Devs!
> > >
> > > We are on track for our planned 1.0.0 release timeline. There are no
> > > outstanding blocker issues on JIRA for the release.
> > >
> > > There are 3 outstanding new feature PRs. They are all in pretty good
> > shape
> > > and should be merged within a day:
> > > https://github.com/apache/flink-kubernetes-operator/pull/213
> > > https://github.com/apache/flink-kubernetes-operator/pull/216
> > > https://github.com/apache/flink-kubernetes-operator/pull/217
> > >
> > > As we agreed previously we should not merge any more new features for
> > > 1.0.0 and focus our efforts on testing, bug fixes and documentation for
> > > this week.
> > >
> > > I will cut the release branch tomorrow once these PRs are merged. And the
> > > target day for the first release candidate is next Monday.
> > >
> > > The release managers for this release will be Yang Wang and myself.
> > >
> > > Cheers,
> > > Gyula
> > >
> > > On Wed, Apr 27, 2022 at 11:28 AM Yang Wang <da...@gmail.com>
> > wrote:
> > >
> > >> Thanks @Chesnay Schepler <ch...@apache.org> for pointing out this.
> > >>
> > >> The only public interface the flink-kubernetes-operator provides is the
> > >> CRD[1]. We are trying to stabilize the CRD from v1beta1.
> > >> If more fields are introduced to support new features(e.g. standalone
> > >> mode,
> > >> SQL jobs), they should have the default value to ensure compatibility.
> > >> Currently, we do not have some tools to enforce the compatibility
> > >> guarantees. But we have created a ticket[1] to follow this and hope it
> > >> could be resolved before releasing 1.0.0.
> > >>
> > >> Just as you said, now is also a good time to think more about the
> > approach
> > >> of releases. Since flink-kubernetes-operator is much simpler than Flink,
> > >> we
> > >> could have a shorter release cycle.
> > >> Two month for a major release(1.0, 1.1, etc.) is reasonable to me. And
> > >> this
> > >> could be shorten for the minor releases. Also we need to support at
> > least
> > >> the last two major versions.
> > >>
> > >> Maybe the standalone mode support is a big enough feature for version
> > 2.0.
> > >>
> > >>
> > >> [1].
> > >>
> > >>
> > https://github.com/apache/flink-kubernetes-operator/tree/main/helm/flink-kubernetes-operator/crds
> > >> [2]. https://issues.apache.org/jira/browse/FLINK-26955
> > >>
> > >>
> > >> @Hao t Chang <ht...@us.ibm.com> We do not have regular sync up
> > meeting
> > >> so
> > >> far. But I think we could schedule some sync up for the 1.0.0 release if
> > >> necessary. Anyone who is interested are welcome.
> > >>
> > >>
> > >> Best,
> > >> Yang
> > >>
> > >>
> > >>
> > >>
> > >> Hao t Chang <ht...@us.ibm.com> 于2022年4月27日周三 07:45写道：
> > >>
> > >> > Hi Gyula,
> > >> >
> > >> > Thanks for the release timeline information. I would like to learn the
> > >> > gathered knowledge and volunteer as well. Will there be sync up
> > >> > meeting/call for this collaboration ?
> > >> >
> > >> > From: Gyula Fóra <gy...@apache.org>
> > >> > Date: Monday, April 25, 2022 at 11:22 AM
> > >> > To: dev <de...@flink.apache.org>
> > >> > Subject: [DISCUSS] Next Flink Kubernetes Operator release timeline
> > >> > Hi Devs!
> > >> >
> > >> > The community has been working hard on cleaning up the operator logic
> > >> and
> > >> > adding some core features that have been missing from the preview
> > >> release
> > >> > (session jobs for example). We have also added some significant
> > >> > improvements around deployment/operations.
> > >> >
> > >> > With the current pace of the development I think in a few weeks we
> > >> should
> > >> > be in a good position to release next version of the operator. This
> > >> would
> > >> > also give us the opportunity to add support for the upcoming 1.15
> > >> release
> > >> > :)
> > >> >
> > >> > We have to decide on 2 main things:
> > >> > 1. Target release date
> > >> > 2. Release version
> > >> >
> > >> > With the current state of the project I am confident that we could
> > cut a
> > >> > really good release candidate towards the end of May. I would suggest
> > a
> > >> > feature *freeze mid May (May 16)*, with a target *RC0 date of May 23*.
> > >> If
> > >> > on May 16 we feel that we are ready we could also prepare the release
> > >> > candidate earlier.
> > >> >
> > >> > As for the release version, I personally feel that this is a good time
> > >> > for *version
> > >> > 1.0.0*.
> > >> > While 1.0.0 signals a certain confidence in the stability of the
> > current
> > >> > API (compared to the preview release) I would keep the kubernetes
> > >> resource
> > >> > version v1beta1.
> > >> >
> > >> > It would also be great if someone could volunteer to join me to help
> > >> manage
> > >> > the release process this time so I can share the knowledge gathered
> > >> during
> > >> > the preview release :)
> > >> >
> > >> > Let me know what you think!
> > >> >
> > >> > Cheers,
> > >> > Gyula
> > >> >
> > >>
> > >
> >
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Posted by Aitozi <gj...@gmail.com>.
Thanks Gyula. It looks good to me. I could do a favor during the release
also.
Please feel free to ping me to help the doc, release and test work :)
Best,
Aitozi
Yang Wang <da...@gmail.com> 于2022年5月16日周一 21:57写道：
> Thanks Gyula for sharing the progress. It is very likely we could have the
> first release candidate next Monday.
>
> Best,
> Yang
>
> Gyula Fóra <gy...@apache.org> 于2022年5月16日周一 20:50写道：
>
> > Hi Devs!
> >
> > We are on track for our planned 1.0.0 release timeline. There are no
> > outstanding blocker issues on JIRA for the release.
> >
> > There are 3 outstanding new feature PRs. They are all in pretty good
> shape
> > and should be merged within a day:
> > https://github.com/apache/flink-kubernetes-operator/pull/213
> > https://github.com/apache/flink-kubernetes-operator/pull/216
> > https://github.com/apache/flink-kubernetes-operator/pull/217
> >
> > As we agreed previously we should not merge any more new features for
> > 1.0.0 and focus our efforts on testing, bug fixes and documentation for
> > this week.
> >
> > I will cut the release branch tomorrow once these PRs are merged. And the
> > target day for the first release candidate is next Monday.
> >
> > The release managers for this release will be Yang Wang and myself.
> >
> > Cheers,
> > Gyula
> >
> > On Wed, Apr 27, 2022 at 11:28 AM Yang Wang <da...@gmail.com>
> wrote:
> >
> >> Thanks @Chesnay Schepler <ch...@apache.org> for pointing out this.
> >>
> >> The only public interface the flink-kubernetes-operator provides is the
> >> CRD[1]. We are trying to stabilize the CRD from v1beta1.
> >> If more fields are introduced to support new features(e.g. standalone
> >> mode,
> >> SQL jobs), they should have the default value to ensure compatibility.
> >> Currently, we do not have some tools to enforce the compatibility
> >> guarantees. But we have created a ticket[1] to follow this and hope it
> >> could be resolved before releasing 1.0.0.
> >>
> >> Just as you said, now is also a good time to think more about the
> approach
> >> of releases. Since flink-kubernetes-operator is much simpler than Flink,
> >> we
> >> could have a shorter release cycle.
> >> Two month for a major release(1.0, 1.1, etc.) is reasonable to me. And
> >> this
> >> could be shorten for the minor releases. Also we need to support at
> least
> >> the last two major versions.
> >>
> >> Maybe the standalone mode support is a big enough feature for version
> 2.0.
> >>
> >>
> >> [1].
> >>
> >>
> https://github.com/apache/flink-kubernetes-operator/tree/main/helm/flink-kubernetes-operator/crds
> >> [2]. https://issues.apache.org/jira/browse/FLINK-26955
> >>
> >>
> >> @Hao t Chang <ht...@us.ibm.com> We do not have regular sync up
> meeting
> >> so
> >> far. But I think we could schedule some sync up for the 1.0.0 release if
> >> necessary. Anyone who is interested are welcome.
> >>
> >>
> >> Best,
> >> Yang
> >>
> >>
> >>
> >>
> >> Hao t Chang <ht...@us.ibm.com> 于2022年4月27日周三 07:45写道：
> >>
> >> > Hi Gyula,
> >> >
> >> > Thanks for the release timeline information. I would like to learn the
> >> > gathered knowledge and volunteer as well. Will there be sync up
> >> > meeting/call for this collaboration ?
> >> >
> >> > From: Gyula Fóra <gy...@apache.org>
> >> > Date: Monday, April 25, 2022 at 11:22 AM
> >> > To: dev <de...@flink.apache.org>
> >> > Subject: [DISCUSS] Next Flink Kubernetes Operator release timeline
> >> > Hi Devs!
> >> >
> >> > The community has been working hard on cleaning up the operator logic
> >> and
> >> > adding some core features that have been missing from the preview
> >> release
> >> > (session jobs for example). We have also added some significant
> >> > improvements around deployment/operations.
> >> >
> >> > With the current pace of the development I think in a few weeks we
> >> should
> >> > be in a good position to release next version of the operator. This
> >> would
> >> > also give us the opportunity to add support for the upcoming 1.15
> >> release
> >> > :)
> >> >
> >> > We have to decide on 2 main things:
> >> > 1. Target release date
> >> > 2. Release version
> >> >
> >> > With the current state of the project I am confident that we could
> cut a
> >> > really good release candidate towards the end of May. I would suggest
> a
> >> > feature *freeze mid May (May 16)*, with a target *RC0 date of May 23*.
> >> If
> >> > on May 16 we feel that we are ready we could also prepare the release
> >> > candidate earlier.
> >> >
> >> > As for the release version, I personally feel that this is a good time
> >> > for *version
> >> > 1.0.0*.
> >> > While 1.0.0 signals a certain confidence in the stability of the
> current
> >> > API (compared to the preview release) I would keep the kubernetes
> >> resource
> >> > version v1beta1.
> >> >
> >> > It would also be great if someone could volunteer to join me to help
> >> manage
> >> > the release process this time so I can share the knowledge gathered
> >> during
> >> > the preview release :)
> >> >
> >> > Let me know what you think!
> >> >
> >> > Cheers,
> >> > Gyula
> >> >
> >>
> >
>
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Posted by Yang Wang <da...@gmail.com>.
Thanks Gyula for sharing the progress. It is very likely we could have the
first release candidate next Monday.
Best,
Yang
Gyula Fóra <gy...@apache.org> 于2022年5月16日周一 20:50写道：
> Hi Devs!
>
> We are on track for our planned 1.0.0 release timeline. There are no
> outstanding blocker issues on JIRA for the release.
>
> There are 3 outstanding new feature PRs. They are all in pretty good shape
> and should be merged within a day:
> https://github.com/apache/flink-kubernetes-operator/pull/213
> https://github.com/apache/flink-kubernetes-operator/pull/216
> https://github.com/apache/flink-kubernetes-operator/pull/217
>
> As we agreed previously we should not merge any more new features for
> 1.0.0 and focus our efforts on testing, bug fixes and documentation for
> this week.
>
> I will cut the release branch tomorrow once these PRs are merged. And the
> target day for the first release candidate is next Monday.
>
> The release managers for this release will be Yang Wang and myself.
>
> Cheers,
> Gyula
>
> On Wed, Apr 27, 2022 at 11:28 AM Yang Wang <da...@gmail.com> wrote:
>
>> Thanks @Chesnay Schepler <ch...@apache.org> for pointing out this.
>>
>> The only public interface the flink-kubernetes-operator provides is the
>> CRD[1]. We are trying to stabilize the CRD from v1beta1.
>> If more fields are introduced to support new features(e.g. standalone
>> mode,
>> SQL jobs), they should have the default value to ensure compatibility.
>> Currently, we do not have some tools to enforce the compatibility
>> guarantees. But we have created a ticket[1] to follow this and hope it
>> could be resolved before releasing 1.0.0.
>>
>> Just as you said, now is also a good time to think more about the approach
>> of releases. Since flink-kubernetes-operator is much simpler than Flink,
>> we
>> could have a shorter release cycle.
>> Two month for a major release(1.0, 1.1, etc.) is reasonable to me. And
>> this
>> could be shorten for the minor releases. Also we need to support at least
>> the last two major versions.
>>
>> Maybe the standalone mode support is a big enough feature for version 2.0.
>>
>>
>> [1].
>>
>> https://github.com/apache/flink-kubernetes-operator/tree/main/helm/flink-kubernetes-operator/crds
>> [2]. https://issues.apache.org/jira/browse/FLINK-26955
>>
>>
>> @Hao t Chang <ht...@us.ibm.com> We do not have regular sync up meeting
>> so
>> far. But I think we could schedule some sync up for the 1.0.0 release if
>> necessary. Anyone who is interested are welcome.
>>
>>
>> Best,
>> Yang
>>
>>
>>
>>
>> Hao t Chang <ht...@us.ibm.com> 于2022年4月27日周三 07:45写道：
>>
>> > Hi Gyula,
>> >
>> > Thanks for the release timeline information. I would like to learn the
>> > gathered knowledge and volunteer as well. Will there be sync up
>> > meeting/call for this collaboration ?
>> >
>> > From: Gyula Fóra <gy...@apache.org>
>> > Date: Monday, April 25, 2022 at 11:22 AM
>> > To: dev <de...@flink.apache.org>
>> > Subject: [DISCUSS] Next Flink Kubernetes Operator release timeline
>> > Hi Devs!
>> >
>> > The community has been working hard on cleaning up the operator logic
>> and
>> > adding some core features that have been missing from the preview
>> release
>> > (session jobs for example). We have also added some significant
>> > improvements around deployment/operations.
>> >
>> > With the current pace of the development I think in a few weeks we
>> should
>> > be in a good position to release next version of the operator. This
>> would
>> > also give us the opportunity to add support for the upcoming 1.15
>> release
>> > :)
>> >
>> > We have to decide on 2 main things:
>> > 1. Target release date
>> > 2. Release version
>> >
>> > With the current state of the project I am confident that we could cut a
>> > really good release candidate towards the end of May. I would suggest a
>> > feature *freeze mid May (May 16)*, with a target *RC0 date of May 23*.
>> If
>> > on May 16 we feel that we are ready we could also prepare the release
>> > candidate earlier.
>> >
>> > As for the release version, I personally feel that this is a good time
>> > for *version
>> > 1.0.0*.
>> > While 1.0.0 signals a certain confidence in the stability of the current
>> > API (compared to the preview release) I would keep the kubernetes
>> resource
>> > version v1beta1.
>> >
>> > It would also be great if someone could volunteer to join me to help
>> manage
>> > the release process this time so I can share the knowledge gathered
>> during
>> > the preview release :)
>> >
>> > Let me know what you think!
>> >
>> > Cheers,
>> > Gyula
>> >
>>
>
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Posted by Gyula Fóra <gy...@apache.org>.
Hi Devs!
We are on track for our planned 1.0.0 release timeline. There are no
outstanding blocker issues on JIRA for the release.
There are 3 outstanding new feature PRs. They are all in pretty good shape
and should be merged within a day:
https://github.com/apache/flink-kubernetes-operator/pull/213
https://github.com/apache/flink-kubernetes-operator/pull/216
https://github.com/apache/flink-kubernetes-operator/pull/217
As we agreed previously we should not merge any more new features for 1.0.0
and focus our efforts on testing, bug fixes and documentation for this week.
I will cut the release branch tomorrow once these PRs are merged. And the
target day for the first release candidate is next Monday.
The release managers for this release will be Yang Wang and myself.
Cheers,
Gyula
On Wed, Apr 27, 2022 at 11:28 AM Yang Wang <da...@gmail.com> wrote:
> Thanks @Chesnay Schepler <ch...@apache.org> for pointing out this.
>
> The only public interface the flink-kubernetes-operator provides is the
> CRD[1]. We are trying to stabilize the CRD from v1beta1.
> If more fields are introduced to support new features(e.g. standalone mode,
> SQL jobs), they should have the default value to ensure compatibility.
> Currently, we do not have some tools to enforce the compatibility
> guarantees. But we have created a ticket[1] to follow this and hope it
> could be resolved before releasing 1.0.0.
>
> Just as you said, now is also a good time to think more about the approach
> of releases. Since flink-kubernetes-operator is much simpler than Flink, we
> could have a shorter release cycle.
> Two month for a major release(1.0, 1.1, etc.) is reasonable to me. And this
> could be shorten for the minor releases. Also we need to support at least
> the last two major versions.
>
> Maybe the standalone mode support is a big enough feature for version 2.0.
>
>
> [1].
>
> https://github.com/apache/flink-kubernetes-operator/tree/main/helm/flink-kubernetes-operator/crds
> [2]. https://issues.apache.org/jira/browse/FLINK-26955
>
>
> @Hao t Chang <ht...@us.ibm.com> We do not have regular sync up meeting
> so
> far. But I think we could schedule some sync up for the 1.0.0 release if
> necessary. Anyone who is interested are welcome.
>
>
> Best,
> Yang
>
>
>
>
> Hao t Chang <ht...@us.ibm.com> 于2022年4月27日周三 07:45写道：
>
> > Hi Gyula,
> >
> > Thanks for the release timeline information. I would like to learn the
> > gathered knowledge and volunteer as well. Will there be sync up
> > meeting/call for this collaboration ?
> >
> > From: Gyula Fóra <gy...@apache.org>
> > Date: Monday, April 25, 2022 at 11:22 AM
> > To: dev <de...@flink.apache.org>
> > Subject: [DISCUSS] Next Flink Kubernetes Operator release timeline
> > Hi Devs!
> >
> > The community has been working hard on cleaning up the operator logic and
> > adding some core features that have been missing from the preview release
> > (session jobs for example). We have also added some significant
> > improvements around deployment/operations.
> >
> > With the current pace of the development I think in a few weeks we should
> > be in a good position to release next version of the operator. This would
> > also give us the opportunity to add support for the upcoming 1.15 release
> > :)
> >
> > We have to decide on 2 main things:
> > 1. Target release date
> > 2. Release version
> >
> > With the current state of the project I am confident that we could cut a
> > really good release candidate towards the end of May. I would suggest a
> > feature *freeze mid May (May 16)*, with a target *RC0 date of May 23*. If
> > on May 16 we feel that we are ready we could also prepare the release
> > candidate earlier.
> >
> > As for the release version, I personally feel that this is a good time
> > for *version
> > 1.0.0*.
> > While 1.0.0 signals a certain confidence in the stability of the current
> > API (compared to the preview release) I would keep the kubernetes
> resource
> > version v1beta1.
> >
> > It would also be great if someone could volunteer to join me to help
> manage
> > the release process this time so I can share the knowledge gathered
> during
> > the preview release :)
> >
> > Let me know what you think!
> >
> > Cheers,
> > Gyula
> >
>
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Posted by Yang Wang <da...@gmail.com>.
Thanks @Chesnay Schepler <ch...@apache.org> for pointing out this.
The only public interface the flink-kubernetes-operator provides is the
CRD[1]. We are trying to stabilize the CRD from v1beta1.
If more fields are introduced to support new features(e.g. standalone mode,
SQL jobs), they should have the default value to ensure compatibility.
Currently, we do not have some tools to enforce the compatibility
guarantees. But we have created a ticket[1] to follow this and hope it
could be resolved before releasing 1.0.0.
Just as you said, now is also a good time to think more about the approach
of releases. Since flink-kubernetes-operator is much simpler than Flink, we
could have a shorter release cycle.
Two month for a major release(1.0, 1.1, etc.) is reasonable to me. And this
could be shorten for the minor releases. Also we need to support at least
the last two major versions.
Maybe the standalone mode support is a big enough feature for version 2.0.
[1].
https://github.com/apache/flink-kubernetes-operator/tree/main/helm/flink-kubernetes-operator/crds
[2]. https://issues.apache.org/jira/browse/FLINK-26955
@Hao t Chang <ht...@us.ibm.com> We do not have regular sync up meeting so
far. But I think we could schedule some sync up for the 1.0.0 release if
necessary. Anyone who is interested are welcome.
Best,
Yang
Hao t Chang <ht...@us.ibm.com> 于2022年4月27日周三 07:45写道：
> Hi Gyula,
>
> Thanks for the release timeline information. I would like to learn the
> gathered knowledge and volunteer as well. Will there be sync up
> meeting/call for this collaboration ?
>
> From: Gyula Fóra <gy...@apache.org>
> Date: Monday, April 25, 2022 at 11:22 AM
> To: dev <de...@flink.apache.org>
> Subject: [DISCUSS] Next Flink Kubernetes Operator release timeline
> Hi Devs!
>
> The community has been working hard on cleaning up the operator logic and
> adding some core features that have been missing from the preview release
> (session jobs for example). We have also added some significant
> improvements around deployment/operations.
>
> With the current pace of the development I think in a few weeks we should
> be in a good position to release next version of the operator. This would
> also give us the opportunity to add support for the upcoming 1.15 release
> :)
>
> We have to decide on 2 main things:
> 1. Target release date
> 2. Release version
>
> With the current state of the project I am confident that we could cut a
> really good release candidate towards the end of May. I would suggest a
> feature *freeze mid May (May 16)*, with a target *RC0 date of May 23*. If
> on May 16 we feel that we are ready we could also prepare the release
> candidate earlier.
>
> As for the release version, I personally feel that this is a good time
> for *version
> 1.0.0*.
> While 1.0.0 signals a certain confidence in the stability of the current
> API (compared to the preview release) I would keep the kubernetes resource
> version v1beta1.
>
> It would also be great if someone could volunteer to join me to help manage
> the release process this time so I can share the knowledge gathered during
> the preview release :)
>
> Let me know what you think!
>
> Cheers,
> Gyula
>
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Posted by Hao t Chang <ht...@us.ibm.com>.
Hi Gyula,
Thanks for the release timeline information. I would like to learn the gathered knowledge and volunteer as well. Will there be sync up meeting/call for this collaboration ?
From: Gyula Fóra <gy...@apache.org>
Date: Monday, April 25, 2022 at 11:22 AM
To: dev <de...@flink.apache.org>
Subject: [DISCUSS] Next Flink Kubernetes Operator release timeline
Hi Devs!
The community has been working hard on cleaning up the operator logic and
adding some core features that have been missing from the preview release
(session jobs for example). We have also added some significant
improvements around deployment/operations.
With the current pace of the development I think in a few weeks we should
be in a good position to release next version of the operator. This would
also give us the opportunity to add support for the upcoming 1.15 release :)
We have to decide on 2 main things:
1. Target release date
2. Release version
With the current state of the project I am confident that we could cut a
really good release candidate towards the end of May. I would suggest a
feature *freeze mid May (May 16)*, with a target *RC0 date of May 23*. If
on May 16 we feel that we are ready we could also prepare the release
candidate earlier.
As for the release version, I personally feel that this is a good time
for *version
1.0.0*.
While 1.0.0 signals a certain confidence in the stability of the current
API (compared to the preview release) I would keep the kubernetes resource
version v1beta1.
It would also be great if someone could volunteer to join me to help manage
the release process this time so I can share the knowledge gathered during
the preview release :)
Let me know what you think!
Cheers,
Gyula
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Posted by Chesnay Schepler <ch...@apache.org>.
Just wanted to point out that when we release 1.0.0 we inevitably also
have to think about what compatibility guarantees we want to give and
how we intend to enforce them.
Additionally it would be good to think about the general approach of
releases; how often are minor/patch releases made, how many versions are
supported, what our plans are for 2.0 (just so we don't end up again in
a situation where we are seemingly unable to release version 2.0).
On 26/04/2022 17:29, Geng Biao wrote:
> Thanks for starting the discussion. It is exciting to learn about the plan of 1.0.0 version!
> The timeline is fine to me. As for the SQL support, as Yang said, I have got some basic ideas and try to make a PoC for verification. It may be first implemented in upstream flink project and then utilized in the k8s operator. I hope to start a discussion about it soon. And it makes sense to me to leave it to next major release.
>
> Thanks all guys again for the awesome work.
> Best,
> Biao Geng
>
> 获取 Outlook for iOS<https://aka.ms/o0ukef>
> ________________________________
> 发件人: Aitozi <gj...@gmail.com>
> 发送时间: Tuesday, April 26, 2022 10:59:39 PM
> 收件人: dev@flink.apache.org <de...@flink.apache.org>
> 主题: Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
>
> Thanks Gyula for starting this discussion.
>
> The release time looks good to me. The main code for the session job is
> complete,
> the doc and other side issues are on the way. I will ping you guys in the
> ticket
> after the work are completed from my side to help review together whether
> there is functionality missing or not (Maybe at the beginning of the May).
>
> Best,
> Aitozi.
>
> Yang Wang <da...@gmail.com> 于2022年4月26日周二 16:07写道：
>
>> Thanks Gyula for starting this discussion.
>>
>> Some users from different companies are also very interested in
>> flink-kubernetes-operator project and asked me in private when it will be
>> production ready.
>> Now I would say the release 1.0.0 aims to this mission.
>>
>> Given that the SQL support in flink-kubernetes-operator is still under PoC
>> and users could use tableAPI to work around, I would like to leave it in
>> the next major version(1.1). cc @Biao Geng
>> So the release pace, including the feature freeze, the release candidate,
>> looks really good to me.
>>
>> I volunteer to help to manage the release 1.0.0 and glad to learn the
>> knowledge you have obtained.
>>
>>
>> Best,
>> Yang
>>
>>
>> Gyula Fóra <gy...@apache.org> 于2022年4月26日周二 02:22写道：
>>
>>> Hi Devs!
>>>
>>> The community has been working hard on cleaning up the operator logic and
>>> adding some core features that have been missing from the preview release
>>> (session jobs for example). We have also added some significant
>>> improvements around deployment/operations.
>>>
>>> With the current pace of the development I think in a few weeks we should
>>> be in a good position to release next version of the operator. This would
>>> also give us the opportunity to add support for the upcoming 1.15 release
>>> :)
>>>
>>> We have to decide on 2 main things:
>>> 1. Target release date
>>> 2. Release version
>>>
>>> With the current state of the project I am confident that we could cut a
>>> really good release candidate towards the end of May. I would suggest a
>>> feature *freeze mid May (May 16)*, with a target *RC0 date of May 23*. If
>>> on May 16 we feel that we are ready we could also prepare the release
>>> candidate earlier.
>>>
>>> As for the release version, I personally feel that this is a good time
>>> for *version
>>> 1.0.0*.
>>> While 1.0.0 signals a certain confidence in the stability of the current
>>> API (compared to the preview release) I would keep the kubernetes
>> resource
>>> version v1beta1.
>>>
>>> It would also be great if someone could volunteer to join me to help
>> manage
>>> the release process this time so I can share the knowledge gathered
>> during
>>> the preview release :)
>>>
>>> Let me know what you think!
>>>
>>> Cheers,
>>> Gyula
>>>
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Posted by Geng Biao <bi...@gmail.com>.
Thanks for starting the discussion. It is exciting to learn about the plan of 1.0.0 version!
The timeline is fine to me. As for the SQL support, as Yang said, I have got some basic ideas and try to make a PoC for verification. It may be first implemented in upstream flink project and then utilized in the k8s operator. I hope to start a discussion about it soon. And it makes sense to me to leave it to next major release.
Thanks all guys again for the awesome work.
Best,
Biao Geng
获取 Outlook for iOS<https://aka.ms/o0ukef>
________________________________
发件人: Aitozi <gj...@gmail.com>
发送时间: Tuesday, April 26, 2022 10:59:39 PM
收件人: dev@flink.apache.org <de...@flink.apache.org>
主题: Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Thanks Gyula for starting this discussion.
The release time looks good to me. The main code for the session job is
complete,
the doc and other side issues are on the way. I will ping you guys in the
ticket
after the work are completed from my side to help review together whether
there is functionality missing or not (Maybe at the beginning of the May).
Best,
Aitozi.
Yang Wang <da...@gmail.com> 于2022年4月26日周二 16:07写道：
> Thanks Gyula for starting this discussion.
>
> Some users from different companies are also very interested in
> flink-kubernetes-operator project and asked me in private when it will be
> production ready.
> Now I would say the release 1.0.0 aims to this mission.
>
> Given that the SQL support in flink-kubernetes-operator is still under PoC
> and users could use tableAPI to work around, I would like to leave it in
> the next major version(1.1). cc @Biao Geng
> So the release pace, including the feature freeze, the release candidate,
> looks really good to me.
>
> I volunteer to help to manage the release 1.0.0 and glad to learn the
> knowledge you have obtained.
>
>
> Best,
> Yang
>
>
> Gyula Fóra <gy...@apache.org> 于2022年4月26日周二 02:22写道：
>
> > Hi Devs!
> >
> > The community has been working hard on cleaning up the operator logic and
> > adding some core features that have been missing from the preview release
> > (session jobs for example). We have also added some significant
> > improvements around deployment/operations.
> >
> > With the current pace of the development I think in a few weeks we should
> > be in a good position to release next version of the operator. This would
> > also give us the opportunity to add support for the upcoming 1.15 release
> > :)
> >
> > We have to decide on 2 main things:
> > 1. Target release date
> > 2. Release version
> >
> > With the current state of the project I am confident that we could cut a
> > really good release candidate towards the end of May. I would suggest a
> > feature *freeze mid May (May 16)*, with a target *RC0 date of May 23*. If
> > on May 16 we feel that we are ready we could also prepare the release
> > candidate earlier.
> >
> > As for the release version, I personally feel that this is a good time
> > for *version
> > 1.0.0*.
> > While 1.0.0 signals a certain confidence in the stability of the current
> > API (compared to the preview release) I would keep the kubernetes
> resource
> > version v1beta1.
> >
> > It would also be great if someone could volunteer to join me to help
> manage
> > the release process this time so I can share the knowledge gathered
> during
> > the preview release :)
> >
> > Let me know what you think!
> >
> > Cheers,
> > Gyula
> >
>
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Posted by Aitozi <gj...@gmail.com>.
Thanks Gyula for starting this discussion.
The release time looks good to me. The main code for the session job is
complete,
the doc and other side issues are on the way. I will ping you guys in the
ticket
after the work are completed from my side to help review together whether
there is functionality missing or not (Maybe at the beginning of the May).
Best,
Aitozi.
Yang Wang <da...@gmail.com> 于2022年4月26日周二 16:07写道：
> Thanks Gyula for starting this discussion.
>
> Some users from different companies are also very interested in
> flink-kubernetes-operator project and asked me in private when it will be
> production ready.
> Now I would say the release 1.0.0 aims to this mission.
>
> Given that the SQL support in flink-kubernetes-operator is still under PoC
> and users could use tableAPI to work around, I would like to leave it in
> the next major version(1.1). cc @Biao Geng
> So the release pace, including the feature freeze, the release candidate,
> looks really good to me.
>
> I volunteer to help to manage the release 1.0.0 and glad to learn the
> knowledge you have obtained.
>
>
> Best,
> Yang
>
>
> Gyula Fóra <gy...@apache.org> 于2022年4月26日周二 02:22写道：
>
> > Hi Devs!
> >
> > The community has been working hard on cleaning up the operator logic and
> > adding some core features that have been missing from the preview release
> > (session jobs for example). We have also added some significant
> > improvements around deployment/operations.
> >
> > With the current pace of the development I think in a few weeks we should
> > be in a good position to release next version of the operator. This would
> > also give us the opportunity to add support for the upcoming 1.15 release
> > :)
> >
> > We have to decide on 2 main things:
> > 1. Target release date
> > 2. Release version
> >
> > With the current state of the project I am confident that we could cut a
> > really good release candidate towards the end of May. I would suggest a
> > feature *freeze mid May (May 16)*, with a target *RC0 date of May 23*. If
> > on May 16 we feel that we are ready we could also prepare the release
> > candidate earlier.
> >
> > As for the release version, I personally feel that this is a good time
> > for *version
> > 1.0.0*.
> > While 1.0.0 signals a certain confidence in the stability of the current
> > API (compared to the preview release) I would keep the kubernetes
> resource
> > version v1beta1.
> >
> > It would also be great if someone could volunteer to join me to help
> manage
> > the release process this time so I can share the knowledge gathered
> during
> > the preview release :)
> >
> > Let me know what you think!
> >
> > Cheers,
> > Gyula
> >
>
Re: [DISCUSS] Next Flink Kubernetes Operator release timeline
Posted by Yang Wang <da...@gmail.com>.
Thanks Gyula for starting this discussion.
Some users from different companies are also very interested in
flink-kubernetes-operator project and asked me in private when it will be
production ready.
Now I would say the release 1.0.0 aims to this mission.
Given that the SQL support in flink-kubernetes-operator is still under PoC
and users could use tableAPI to work around, I would like to leave it in
the next major version(1.1). cc @Biao Geng
So the release pace, including the feature freeze, the release candidate,
looks really good to me.
I volunteer to help to manage the release 1.0.0 and glad to learn the
knowledge you have obtained.
Best,
Yang
Gyula Fóra <gy...@apache.org> 于2022年4月26日周二 02:22写道：
> Hi Devs!
>
> The community has been working hard on cleaning up the operator logic and
> adding some core features that have been missing from the preview release
> (session jobs for example). We have also added some significant
> improvements around deployment/operations.
>
> With the current pace of the development I think in a few weeks we should
> be in a good position to release next version of the operator. This would
> also give us the opportunity to add support for the upcoming 1.15 release
> :)
>
> We have to decide on 2 main things:
> 1. Target release date
> 2. Release version
>
> With the current state of the project I am confident that we could cut a
> really good release candidate towards the end of May. I would suggest a
> feature *freeze mid May (May 16)*, with a target *RC0 date of May 23*. If
> on May 16 we feel that we are ready we could also prepare the release
> candidate earlier.
>
> As for the release version, I personally feel that this is a good time
> for *version
> 1.0.0*.
> While 1.0.0 signals a certain confidence in the stability of the current
> API (compared to the preview release) I would keep the kubernetes resource
> version v1beta1.
>
> It would also be great if someone could volunteer to join me to help manage
> the release process this time so I can share the knowledge gathered during
> the preview release :)
>
> Let me know what you think!
>
> Cheers,
> Gyula
>