zentol commented on pull request #14630: URL: https://github.com/apache/flink/pull/14630#issuecomment-762209580
@tianon Note that the stance against blackboxes and against kubernetes-specific branches creates quite a few issues, and at this point I honestly do not know what is acceptable and what isn't. a) If deferring the entire logic to some script outside the image is a problem, then so should any approach that allows an arbitrary command to be run (i.e., what was introduced in https://github.com/apache/flink-docker/pull/49). Both do _something unspecified_, having _some unspecified requirements_. I cannot comprehend why the latter was seemingly accepted though; we could now remove all the other branches and route everything through the generic path, leaving us in eventually the same state that we are in with this PR. b) The reality is we need some hook to activate some kubernetes-specific code; that's the whole point of our _native_ kubernetes integration (you _can_ still run things on kubernetes without it, this is just an _option_). We can't have kubernetes-specific branches in the image, and with generic branches being ruled out by a) the only alternative is adding a new `isKubernetes` flag argument to existing scripts in the distribution. This flag would not be mentioned in the image at all (it would just one of many arguments passed as parameter to the bin/ scripts), effectively being a hidden kubernetes branch. I feel like that _shouldn't_ be acceptable because we'd just be tip-toeing around the issue and the scripts using that flag would again, from the perspective of the image, could be considered a black box. To be specific, the jobmanager.sh would then either start a generic jobmanager (one that would be used outside docker environments) or one specific to kubernetes based on a given argument. But if that were allowed, then I'd think a script that starts either a jobmanager or taskmanager based on some argument should also be allowed. You can apply this logic a few more times and end up with a single scripts starting some process, which was already rejected. But then I don't see a way how applications could implement anything optional that is specific to kubernetes and conform to your rules. ---------------------------------------------------------------- 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
