Re: [DISCUSS] Kubernetes Operator 1.7.0 release planning
+1 for targeting the release as soon as possible. Given the effort that Rui has undergone to decouple the autoscaling implementation, it makes sense to also include an alternative implementation with the release. In the long run, I wonder whether the standalone implementation should even be part of the Kubernetes operator repository. It can be hosted in a different repository and simply consume the flink-autoscaler jar. But the same applies to the flink-autoscaler module. For this release, we can keep everything together. I have a minor issue [1] I would like to include in the release. -Max [1] https://issues.apache.org/jira/browse/FLINK-33429 On Tue, Oct 31, 2023 at 11:14 AM Rui Fan <1996fan...@gmail.com> wrote: > > Thanks Gyula for driving this release! > > I'd like to check with you and community, could we > postpone the code freeze by a week? > > I'm developing the FLINK-33099[1], and the prod code is done. > I need some time to develop the tests. I hope this feature is included in > 1.7.0 for two main reasons: > > 1. We have completed the decoupling of the autoscaler and > kubernetes-operator in 1.7.0. During the decoupling period, we modified > a large number of autoscaler-related interfaces. The standalone autoscaler > is an autoscaler process that can run independently. It can help us confirm > whether the new interface is reasonable. > 2. 1.18.0 was recently released, standalone autoscaler allows more users to > play autoscaler and in-place rescale. > > I have created a draft PR[2] for FLINK-33099, it just includes prod code. > I have run it manually, it works well. And I will try my best to finish all > unit tests before Friday, but must finish all unit tests before next Monday > at the latest. > > WDYT? > > I'm deeply sorry for the request to postpone the release. > > [1] https://issues.apache.org/jira/browse/FLINK-33099 > [2] https://github.com/apache/flink-kubernetes-operator/pull/698 > > Best, > Rui > > On Tue, Oct 31, 2023 at 4:10 PM Samrat Deb wrote: > > > Thank you Gyula > > > > (+1 non-binding) in support of you taking on the role of release manager. > > > > > I think this is reasonable as I am not aware of any big features / bug > > fixes being worked on right now. Given the size of the changes related to > > the autoscaler module refactor we should try to focus the remaining time on > > testing. > > > > I completely agree with you. Since the changes are quite extensive, it's > > crucial to allocate more time for thorough testing and verification. > > > > Regarding working with you for the release, I might not have the necessary > > privileges for that. > > > > However, I'd be more than willing to assist with testing the changes, > > validating various features, and checking for any potential regressions in > > the flink-kubernetes-operator. > > Just let me know how I can support the testing efforts. > > > > Bests, > > Samrat > > > > > > On Tue, 31 Oct 2023 at 12:59 AM, Gyula Fóra wrote: > > > > > Hi all! > > > > > > I would like to kick off the release planning for the operator 1.7.0 > > > release. We have added quite a lot of new functionality over the last few > > > weeks and I think the operator is in a good state to kick this off. > > > > > > Based on the original release schedule we had Nov 1 as the proposed > > feature > > > freeze date and Nov 7 as the date for the release cut / rc1. > > > > > > I think this is reasonable as I am not aware of any big features / bug > > > fixes being worked on right now. Given the size of the changes related to > > > the autoscaler module refactor we should try to focus the remaining time > > on > > > testing. > > > > > > I am happy to volunteer as a release manager but I am of course open to > > > working together with someone on this. > > > > > > What do you think? > > > > > > Cheers, > > > Gyula > > > > >
Re: [DISCUSS] Kubernetes Operator 1.7.0 release planning
Thanks Gyula for driving this release! I'd like to check with you and community, could we postpone the code freeze by a week? I'm developing the FLINK-33099[1], and the prod code is done. I need some time to develop the tests. I hope this feature is included in 1.7.0 for two main reasons: 1. We have completed the decoupling of the autoscaler and kubernetes-operator in 1.7.0. During the decoupling period, we modified a large number of autoscaler-related interfaces. The standalone autoscaler is an autoscaler process that can run independently. It can help us confirm whether the new interface is reasonable. 2. 1.18.0 was recently released, standalone autoscaler allows more users to play autoscaler and in-place rescale. I have created a draft PR[2] for FLINK-33099, it just includes prod code. I have run it manually, it works well. And I will try my best to finish all unit tests before Friday, but must finish all unit tests before next Monday at the latest. WDYT? I'm deeply sorry for the request to postpone the release. [1] https://issues.apache.org/jira/browse/FLINK-33099 [2] https://github.com/apache/flink-kubernetes-operator/pull/698 Best, Rui On Tue, Oct 31, 2023 at 4:10 PM Samrat Deb wrote: > Thank you Gyula > > (+1 non-binding) in support of you taking on the role of release manager. > > > I think this is reasonable as I am not aware of any big features / bug > fixes being worked on right now. Given the size of the changes related to > the autoscaler module refactor we should try to focus the remaining time on > testing. > > I completely agree with you. Since the changes are quite extensive, it's > crucial to allocate more time for thorough testing and verification. > > Regarding working with you for the release, I might not have the necessary > privileges for that. > > However, I'd be more than willing to assist with testing the changes, > validating various features, and checking for any potential regressions in > the flink-kubernetes-operator. > Just let me know how I can support the testing efforts. > > Bests, > Samrat > > > On Tue, 31 Oct 2023 at 12:59 AM, Gyula Fóra wrote: > > > Hi all! > > > > I would like to kick off the release planning for the operator 1.7.0 > > release. We have added quite a lot of new functionality over the last few > > weeks and I think the operator is in a good state to kick this off. > > > > Based on the original release schedule we had Nov 1 as the proposed > feature > > freeze date and Nov 7 as the date for the release cut / rc1. > > > > I think this is reasonable as I am not aware of any big features / bug > > fixes being worked on right now. Given the size of the changes related to > > the autoscaler module refactor we should try to focus the remaining time > on > > testing. > > > > I am happy to volunteer as a release manager but I am of course open to > > working together with someone on this. > > > > What do you think? > > > > Cheers, > > Gyula > > >
Re: [DISCUSS] Kubernetes Operator 1.7.0 release planning
Thank you Gyula (+1 non-binding) in support of you taking on the role of release manager. > I think this is reasonable as I am not aware of any big features / bug fixes being worked on right now. Given the size of the changes related to the autoscaler module refactor we should try to focus the remaining time on testing. I completely agree with you. Since the changes are quite extensive, it's crucial to allocate more time for thorough testing and verification. Regarding working with you for the release, I might not have the necessary privileges for that. However, I'd be more than willing to assist with testing the changes, validating various features, and checking for any potential regressions in the flink-kubernetes-operator. Just let me know how I can support the testing efforts. Bests, Samrat On Tue, 31 Oct 2023 at 12:59 AM, Gyula Fóra wrote: > Hi all! > > I would like to kick off the release planning for the operator 1.7.0 > release. We have added quite a lot of new functionality over the last few > weeks and I think the operator is in a good state to kick this off. > > Based on the original release schedule we had Nov 1 as the proposed feature > freeze date and Nov 7 as the date for the release cut / rc1. > > I think this is reasonable as I am not aware of any big features / bug > fixes being worked on right now. Given the size of the changes related to > the autoscaler module refactor we should try to focus the remaining time on > testing. > > I am happy to volunteer as a release manager but I am of course open to > working together with someone on this. > > What do you think? > > Cheers, > Gyula >
[DISCUSS] Kubernetes Operator 1.7.0 release planning
Hi all! I would like to kick off the release planning for the operator 1.7.0 release. We have added quite a lot of new functionality over the last few weeks and I think the operator is in a good state to kick this off. Based on the original release schedule we had Nov 1 as the proposed feature freeze date and Nov 7 as the date for the release cut / rc1. I think this is reasonable as I am not aware of any big features / bug fixes being worked on right now. Given the size of the changes related to the autoscaler module refactor we should try to focus the remaining time on testing. I am happy to volunteer as a release manager but I am of course open to working together with someone on this. What do you think? Cheers, Gyula
