On Fri, Jan 12, 2018 at 1:53 PM, Anirudh Ramanathan <ramanath...@google.com> wrote: > As I understand, the bigger change discussed here are like the init > containers, which will be more on the implementation side than a user facing > change/behavioral change - which is why it seemed okay to pursue it post 2.3 > as well.
It's not just a code change. There are multiple configurations exposed to control the init container. There's a whole step - the running of the init container - that currently can be customized (even though there is no documentation on how to safely do that). If you ship that as "stable", you cannot later change it in way that will break applications. So you'd not only be stuck with the existence of the init container, but with all its current behavior. Marking as experimental gives us time to stabilize these details. Not just whether the init container exists, but what is its actual behavior and how the use can affect it. A lot of the replies here always mention that init containers can be customized, but I just want to point out again that there is currently zero documentation about how to do that and not break the assumptions the spark-on-k8s submission code makes. The same applies to the other images, by the way. -- Marcelo --------------------------------------------------------------------- To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
