Github user mccheah commented on the issue:
https://github.com/apache/spark/pull/21748
I think taking a step back, it seems unwise more so to be making any
assumptions about the location in which a driver is running in client mode.
Client mode is simply just saying that the application driver is running
"locally", wherever locally is. That is why I suggested also to remove the
driver's knowledge of the driver pod name and to remove the owner reference
concept entirely. As soon as we start to make assumptions in one place, it may
(though not necessarily) encourage us to rely on those assumptions to create
more forks and complexities in the code in other places. That's a precedent we
likely do not want to set.
> Yes, and that's what my point above is about. Regardless of how the
driver pod is created and managed, users need to make sure it contains a label
that is unique for the pod/service combination to work.
In one case the requirement for the unique label is explicit - the user has
created their service and their pod manually and have assigned the labels
accordingly. In another case, the user must know to assign the unique label but
they would only know to do so from having read the documentation on deploying
Spark. Explicit requirements that are well defined by the API are preferable to
implicit requirements.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
