On Wed, Jan 10, 2018 at 2:00 PM, Yinan Li <liyinan...@gmail.com> wrote: > I want to re-iterate on one point, that the init-container achieves a clear > separation between preparing an application and actually running the > application. It's a guarantee provided by the K8s admission control and > scheduling components that if the init-container fails, the main container > won't be run. I think this is definitely positive to have. In the case of a > Spark application, the application code and driver/executor code won't even > be run if the init-container fails to localize any of the dependencies
That is also the case with spark-submit... (can't download dependencies -> spark-submit fails before running user code). > Note that we are not blindly opposing getting rid of the init-container, > it's just that there's still valid reasons to keep it for now I'll flip that around: I'm not against having an init container if it's serving a needed purpose, it's just that nobody is able to tell me what that needed purpose is. 1500 less lines of code trump all of the arguments given so far for what the init container might be a good idea. -- Marcelo --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
