Github user mccheah commented on the issue:
https://github.com/apache/spark/pull/23174
It matters because we're discussing direction - that is, what opinion Spark
wants to take regarding how to set up security on K8s. It's not obvious from
our discussion on SPARK-26239 that we agree that we should allow such
optionality for other authentication schemes. In other words, if we just merge
this PR without further discussion and consensus on SPARK-26239, we're
effectively communicating that Spark is locked in to the authentication backed
by K8s secrets. I want to emphasize that it's important to agree on the
direction for the bigger picture early on, and then we say that this patch
still fits into the bigger vision.
I also want to intend to take this patch and check that work on SPARK-26239
would work nicely with it, but to the best of my knowledge the additional
options should layer on top of this default one just fine. Would like some
concrete prototyping to confirm this though.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
