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
