Github user tnachen commented on the pull request:
https://github.com/apache/spark/pull/4027#issuecomment-164125291
Yes at this moment I'll be closing this PR and move forward with another
proposal that is to use spark.executor.cores and have a new coarse grain
scheduler.
> On Dec 12, 2015, at 4:14 AM, andrewor14 <[email protected]> wrote:
>
> I still think the configs introduced in this patch expose too much to the
average user. It's not straightforward even to me to think about how "max
cores" and "max executors" interact. In the past we have introduced more
complicated configs than necessary and now we're stuck with them due to
backward compatibility. IMO it's always a good idea to first introduce the
simplest set of properties possible and then augment that in the future if
necessary (and 90% of the time it's sufficient).
>
> In this particular case spark.executor.cores has well-understood
semantics in other modes and has been in use for many versions now. It's not
only the simplest but also the most consistent across different cluster
managers in Spark.
>
> â
> Reply to this email directly or view it on GitHub.
>
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
