[
https://issues.apache.org/jira/browse/SPARK-24434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16599380#comment-16599380
]
Felix Cheung commented on SPARK-24434:
--------------------------------------
.. and let's make sure any discussion are summarized and communicated as per
ASF policy (eg. update this JIRA) and be mindful of other's contribution, work
schedule and life style etc.
Sounds like in this case we could:
* record any discussion in k8s sig, slack or offline and communicate in this
Jira and/or to [d...@spark.apache.org|mailto:d...@spark.apache.org]
* give plenty of heads up time to the originator, eg. give people 3-4 days to
response, react etc after directly pinging the person on the Jira or email
* make sure due credit is given in JIra, github PR description etc and link to
any history or reference design doc
* if this PR [https://github.com/apache/spark/pull/22146] is intended to be a
WIP, please mark and describe it as such. As of now I don't see any indication
of it
I believe this would then follow more closely to the convention we have adopted
for the Apache Spark project. As stated, we do not assign Jira to user until
after it is merged and Jira to be resolved, for various reasons. However,
typically contributor expresses their desire to work on something in Jira or
dev@ and wait a bit for feedback or comment.
[~onursatici] could you please update your PR to the effect outlined above?
[~skonto] hopefully this make sense to you and we (Spark, k8s communities)
would still love to work with you, and would like your feedback on guiding the
PR to completion.
> Support user-specified driver and executor pod templates
> --------------------------------------------------------
>
> Key: SPARK-24434
> URL: https://issues.apache.org/jira/browse/SPARK-24434
> Project: Spark
> Issue Type: New Feature
> Components: Kubernetes
> Affects Versions: 2.4.0
> Reporter: Yinan Li
> Priority: Major
>
> With more requests for customizing the driver and executor pods coming, the
> current approach of adding new Spark configuration options has some serious
> drawbacks: 1) it means more Kubernetes specific configuration options to
> maintain, and 2) it widens the gap between the declarative model used by
> Kubernetes and the configuration model used by Spark. We should start
> designing a solution that allows users to specify pod templates as central
> places for all customization needs for the driver and executor pods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org
