tianon commented on pull request #14630: URL: https://github.com/apache/flink/pull/14630#issuecomment-761165429
I agree that the Docker image being a complete black box is a bad thing, which is exactly why I'm confused by this PR. Let me try to rephrase what I'm suggesting: Take a look at the `docker-entrypoint.sh` as it stands today, and identify what problems it solves that are _not_ currently solved by the existing `flink` wrapper script(s) that are shipped with the upstream Flink distribution. Determine what makes sense to add to the Flink distribution to help with those use cases that are currently not being serviced, and use the integration of those changes into `docker-entrypoint.sh` as a "barometer" of sorts for whether you're succeeding at decreasing the amount of above-and-beyond scripting necessary to accomplish these core Flink use cases (because at the end of the day, the length of `docker-entrypoint.sh` is demonstrating that there are gaps in how Flink is expected to be run). I am not suggesting that the code in the current entrypoint script should be simply moved elsewhere, because that doesn't actually solve the underlying problem that the way the Flink distribution officially expects to be run and the way it's being run have diverged. As a concrete example, if someone downloads the binary distribution of Flink and tries to run it on a VM, are they expected to set an appropriate `CLASSPATH` variable? Why or why not? How can we improve the experience for them in such a way that it also improves the experience for Docker? (Alternatively, if they are not, why does the Docker image need to, and how can we bring those two usages into a more symbiotic alignment?) ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
