@Till, Thanks for volunteering.
@Konstantin, >From my experience, the effort that requires DockerHub access in the main project release process is quite limited. I helped Yun Gao on releasing the 1.15.0 images, and what I did was just check out the `flink-docker` repo and run the release script, that's it. If all the sub-projects are as easy as the main project, then it's probably ok that only a small group of people have access. Concerning the redundancy, if a maintainer from a sub-project is temporarily unreachable, I believe the other maintainers would be glad to help. It would of course be good to have more seats. I just haven't come up with good reasons to persuade the INFRA folks. What's your suggestions? Thank you~ Xintong Song On Fri, May 6, 2022 at 6:38 PM Konstantin Knauf <kna...@apache.org> wrote: > 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 >
