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