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 > >>>> > >>>> > >> > >
