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