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