Hi Xintong, it is a pity that we can only have 5 maintainers. Every (patch) release of flink, flink-statefun, the flink-kubernetes-operator requires a maintainer to publish the image then, if I am not mistaken. As its mostly different groups managing the sub-projects, this is quite the bottleneck. If we give one seat to flink-statefun maintainers, one to the flink-kubernetes-operator maintainers, this leaves three seats for Apache Flink core, and there is no redundancy for the other projects. When I managed the last two patch releases, the DockerHub access was also the biggest hurdle. Maybe we can talk to the INFRA people again. We can certainly reduce it, but 5 is very little.
Cheers, Konstantin Am Fr., 6. Mai 2022 um 09:00 Uhr schrieb Till Rohrmann <trohrm...@apache.org >: > Hi everyone, > > thanks for starting this discussion Xintong. I would volunteer as a > maintainer of the flink-statefun Docker repository if you need one. > > Cheers, > Till > > On Fri, May 6, 2022 at 6:22 AM Xintong Song <tonysong...@gmail.com> wrote: > >> It seems to me we at least don't have a consensus on dropping the use of >> apache namespace, which means we need to decide on a list of maintainers >> anyway. So maybe we can get the discussion back to the maintainers. We may >> continue the official-image vs. apache-namespace in a separate thread if >> necessary. >> >> As mentioned previously, we need to reduce the number of maintainers from >> 20 to 5, as required by INFRA. Jingsong and I would like to volunteer as 2 >> of the 5, and we would like to learn who else wants to join us. Of course >> the list of maintainers can be modified later. >> >> *This also means the current maintainers may be removed from the list.* >> Please let us know if you still need that privilege. CC-ed all the current >> maintainers for attention. >> >> Thank you~ >> >> Xintong Song >> >> >> >> On Wed, May 4, 2022 at 3:14 PM Chesnay Schepler <ches...@apache.org> >> wrote: >> >> > One advantage is that the images are periodically rebuilt to get >> > security fixes. >> > >> > The operator is a different story anyway because it is AFAIK only >> > supposed to be used via docker >> > (i.e., no standalone mode), which alleviates concerns about keeping the >> > logic within the image >> > to a minimum (which bit us in the past on the flink side). >> > >> > On 03/05/2022 16:09, Yang Wang wrote: >> > > The flink-kubernetes-operator project is only published >> > > via apache/flink-kubernetes-operator on docker hub and github >> packages. >> > > We do not find the obvious advantages by using docker hub official >> > images. >> > > >> > > Best, >> > > Yang >> > > >> > > Xintong Song <tonysong...@gmail.com> 于2022年4月28日周四 19:27写道： >> > > >> > >> I agree with you that doing QA for the image after the release has >> been >> > >> finalized doesn't feel right. IIUR, that is mostly because official >> > image >> > >> PR needs 1) the binary release being deployed and propagated and 2) >> the >> > >> corresponding git commit being specified. I'm not completely sure >> about >> > >> this. Maybe we can improve the process by investigating more about >> the >> > >> feasibility of pre-verifying an official image PR before finalizing >> the >> > >> release. It's definitely a good thing to do if possible. >> > >> >> > >> I also agree that QA from DockerHub folks is valuable to us. >> > >> >> > >> I'm not against publishing official-images, and I'm not against >> working >> > >> closely with the DockerHub folks to improve the process of delivering >> > the >> > >> official image. However, I don't think these should become reasons >> that >> > we >> > >> don't release our own apache/flink images. >> > >> >> > >> Taking the 1.12.0 as an example, admittedly it would be nice for us >> to >> > >> comply with the DockerHub folks' standards and not have a >> > >> just-for-kubernetes command in our entrypoint. However, this is IMO >> far >> > >> less important compared to delivering the image to our users timely. >> I >> > >> guess that's where the DockerHub folks and us have different >> > >> priorities, and that's why I think we should have a path that is >> fully >> > >> controlled by this community to deliver images. We could take their >> > >> valuable inputs and improve afterwards. Actually, that's what we did >> for >> > >> 1.12.0 by starting to release to apache/flink. >> > >> >> > >> Thank you~ >> > >> >> > >> Xintong Song >> > >> >> > >> >> > >> >> > >> On Thu, Apr 28, 2022 at 6:30 PM Chesnay Schepler <ches...@apache.org >> > >> > >> wrote: >> > >> >> > >>> I still think that's mostly a process issue. >> > >>> Of course we can be blind-sided if we do the QA for a release >> artifact >> > >>> after the release has been finalized. >> > >>> But that's a clearly broken process from the get-go. >> > >>> >> > >>> At the very least we should already open a PR when the RC is >> created to >> > >>> get earlier feedback. >> > >>> >> > >>> Moreover, nowadays the docker images are way slimmer and we are much >> > >>> more careful on what is actually added to the scripts. >> > >>> >> > >>> Finally, the problems they found did show that their QA is very >> > valuable >> > >>> to us. And side-stepping that for such an essential piece of a >> release >> > >>> isn't a good idea imo. >> > >>> >> > >>> On 28/04/2022 11:31, Xintong Song wrote: >> > >>>> I'm overall against only releasing to official-images. >> > >>>> >> > >>>> We started releasing to apache/flink, in addition to the >> > >> official-image, >> > >>> in >> > >>>> 1.12.0. That was because releasing the official-image needs >> approval >> > >> from >> > >>>> the DockerHub folks, which is not under control of the Flink >> > community. >> > >>> For >> > >>>> 1.12.0 there were unfortunately some divergences between us and the >> > >>>> DockerHub folks, and it ended-up taking us nearly 2 months to get >> that >> > >>>> official-image PR merged [1][2]. Many users, especially those who >> need >> > >>>> Flink's K8s & Native-K8s deployment modes, were asking for the >> image >> > >>> after >> > >>>> 1.12.0 was announced. >> > >>>> >> > >>>> One could argue that what happened for 1.12.0 is not a regular >> case. >> > >>>> However, I'd like to point out that the docker images are not >> > something >> > >>>> nice-to-have, but a practically necessary piece of the release for >> the >> > >>> k8s >> > >>>> / native-k8s deployments to work. I'm strongly against a release >> > >> process >> > >>>> where such an important piece depends on the approval of a 3rd >> party. >> > >>>> >> > >>>> Thank you~ >> > >>>> >> > >>>> Xintong Song >> > >>>> >> > >>>> >> > >>>> [1] https://issues.apache.org/jira/browse/FLINK-20650 >> > >>>> >> > >>>> [2] https://github.com/docker-library/official-images/pull/9249 >> > >>>> >> > >>>> >> > >>>> >> > >>>> On Thu, Apr 28, 2022 at 2:43 PM Chesnay Schepler < >> ches...@apache.org> >> > >>> wrote: >> > >>>>> We could just stop releasing to apache/flink and only go for the >> > >>>>> official-images route. >> > >>>>> >> > >>>>> On 28/04/2022 07:43, Xintong Song wrote: >> > >>>>>> Forgot to mention that, we have also proposed to use one shared >> > >> account >> > >>>>> and >> > >>>>>> limit its access to the PMC members, like what we do with the >> PyPI >> > >>>>> account. >> > >>>>>> Unfortunately, INFRA rejected this proposal [1]. >> > >>>>>> >> > >>>>>> >> > >>>>>> Thank you~ >> > >>>>>> >> > >>>>>> Xintong Song >> > >>>>>> >> > >>>>>> >> > >>>>>> [1] https://issues.apache.org/jira/browse/INFRA-23208 >> > >>>>>> >> > >>>>>> On Thu, Apr 28, 2022 at 1:39 PM Xintong Song < >> tonysong...@gmail.com >> > > >> > >>>>> wrote: >> > >>>>>>> Hi devs, >> > >>>>>>> >> > >>>>>>> I'd like to start a discussion about maintainers for DockerHub >> > >>>>>>> repositories under the *apache* namespace [1]. >> > >>>>>>> >> > >>>>>>> Currently, the Flink community maintains various repositories >> > >> (flink, >> > >>>>>>> flink-statefun, flink-statefun-playground, and >> > >>>>> flink-kubernetes-operator) >> > >>>>>>> on DockerHub under the *apache* namespace. There's a limitation >> on >> > >> how >> > >>>>> many >> > >>>>>>> members the *apache* namespace can add, and recently INFRA is >> > >>>>> complaining >> > >>>>>>> about Flink taking too many places [2][3]. They would like us to >> > >>> reduce >> > >>>>> our >> > >>>>>>> maintainers from 20 now to 5. >> > >>>>>>> >> > >>>>>>> Jingsong and I would like to volunteer as two of the >> maintainers, >> > >> and >> > >>> we >> > >>>>>>> would like to learn who else wants to join us. While any >> committer >> > >> may >> > >>>>>>> serve as one of the maintainers, it's probably nice to also >> involve >> > >> at >> > >>>>>>> least one maintainer from statefun and one from >> > kubernetes-operator. >> > >>>>>>> >> > >>>>>>> What do you think? >> > >>>>>>> >> > >>>>>>> Thank you~ >> > >>>>>>> >> > >>>>>>> Xintong Song >> > >>>>>>> >> > >>>>>>> >> > >>>>>>> [1] https://hub.docker.com/orgs/apache >> > >>>>>>> >> > >>>>>>> [2] https://issues.apache.org/jira/browse/INFRA-23208 >> > >>>>>>> >> > >>>>>>> [3] https://issues.apache.org/jira/browse/INFRA-23213 >> > >>>>>>> >> > >>>>>>> >> > >>> >> > >> > >> > -- https://twitter.com/snntrable https://github.com/knaufk
