Hi team, I volunteer for the flink-kubernetes-operator repo.
On Fri, May 6, 2022 at 1:42 PM Xintong Song <tonysong...@gmail.com> wrote: > @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 > > >
