Github user vanzin commented on the issue:
https://github.com/apache/spark/pull/23174
> It matters because we're discussing direction
I'm not, you guys are. I'm adding a missing feature with one particular
implementation. If you want to add other implementations that enable different
use cases, great.
> we're effectively communicating that Spark is locked in to the
authentication backed by K8s secrets
We're not locking into anything, and that's basically where I strongly
disagree with you. You're free to add new ways, and when that's done, you're
not "locked in" anymore.
Locked in would mean that pushing this PR means you cannot make changes to
it later, and that's just not true.
Right now you're "locked in" to no auth at all, but somehow that's ok?
> check that work on SPARK-26239 would work nicely with it
Anything needed to implement that feature is just code changes. Whether it
"works nicely" is just a matter of not breaking this when that feature is
implemented.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
