-
Notifications
You must be signed in to change notification settings - Fork 28k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SPARK-34384][CORE] Add missing docs for ResourceProfile APIs #31496
Conversation
@@ -25,7 +25,7 @@ import org.apache.spark.SparkException | |||
* Trait used to help executor/worker allocate resources. | |||
* Please note that this is intended to be used in a single thread. | |||
*/ | |||
trait ResourceAllocator { | |||
private[spark] trait ResourceAllocator { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This's probably mistakenly exposed in 3.0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this impact folks working on schedulers outside of org.apache.spark?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it wouldn't since there's no way to plug-in a custom ResourceAllocator
in Spark yet.
core/src/main/scala/org/apache/spark/resource/ResourceProfileBuilder.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/org/apache/spark/resource/ResourceProfileBuilder.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/org/apache/spark/resource/ResourceProfileBuilder.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/org/apache/spark/resource/ResourceProfile.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/org/apache/spark/resource/ExecutorResourceRequests.scala
Outdated
Show resolved
Hide resolved
cc @tgravescs @jiangxb1987 @mengxr cc release manager @HyukjinKwon |
core/src/main/scala/org/apache/spark/resource/ResourceProfile.scala
Outdated
Show resolved
Hide resolved
Test build #134953 has finished for PR 31496 at commit
|
Kubernetes integration test starting |
Kubernetes integration test status success |
Kubernetes integration test starting |
Kubernetes integration test status success |
Test build #134954 has finished for PR 31496 at commit
|
Test build #134967 has started for PR 31496 at commit |
Kubernetes integration test starting |
Kubernetes integration test status failure |
I'm -1 for any changes here except maybe docs... it is way to late in the release to be changing api's. This was reviewed and went in. We have already put out an RC and this is not a blocking bug. I don't want last minute changes that were thought about to mess things up. |
I'd really like to express my concern over this PR. There is a reason we go through a SPIP process and review the API's during design and PRs. Many things were discussed, sometimes compromises were made based on feedback, some things may be to allow supporting future enhancements, etc. I really hope this isn't happening in other places in the code. |
I don't think this blocks RC I am preparing now. Same here too. Hope we can do this earlier next time. @tgravescs, though, some of them like https://github.com/apache/spark/pull/31496/files#diff-ee7e90474f1ce0390fce28f5e4d1d1be689c905ed13069bd869c8689a177e154R150 seems making sense. Maybe it wouldn't hurt to do a fine grained review. For the API changes such as https://github.com/apache/spark/pull/31496/files#diff-a6d96a65d9905b310451b125acac6610ffbd6b4548461bd1d5a18dc29282814aL57, we might have to follow the standard deprecation process if we're going to change if we will do. |
@tgravescs I think there are two separate questions:
So how about the following (none blocking 3.1 release):
If we manage to get the above changes into 3.1 in time, I think it would improve API clarity and consistency. Then we can discuss other proposed renaming/refactoring after. Does it sound good? |
The API as you state is Evolving and that is on purpose so we can extend and change as people use it and we learn more. I'm happy to hear the feedback and improve the API during normally development periods, at this point when we already had a 3.1 rc, it is not appropriate to throw API changes in last minute, most of them were discussed and chosen for a reason. This just leads to introducing more issues. I asked repeatedly for people to help review the SPIP and the code along the way - that was the time to help with API changes not right before a release goes out. I think this has happened way to much and I believe even brought up about the 3.0.0 release. That said, non-api changes or obvious small issues in it should be fixed. The third point api's were intentionally added so I'm against that change at this point. It does look like I forgot to add automated tests for it, we can file a jira and I will add them. We shouldn't remove an api because tests were missed. This is user facing api so the fact its not used internally doesn't mean its not useful. You can argue whether a builder should have a clear/remove api, but it really depends on how users use this set of API's. I have seen many builders with remove apis. |
Sounds good. Let's do minimal changes in this PR and open two JIRAs as follow-ups: 1) complete the missing tests, 2) collect API feedback. cc: @Ngone51 @HyukjinKwon |
SGTM |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did a quick skim, thanks for working on improving the javadocs :)
@@ -25,7 +25,7 @@ import org.apache.spark.SparkException | |||
* Trait used to help executor/worker allocate resources. | |||
* Please note that this is intended to be used in a single thread. | |||
*/ | |||
trait ResourceAllocator { | |||
private[spark] trait ResourceAllocator { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would this impact folks working on schedulers outside of org.apache.spark?
core/src/main/scala/org/apache/spark/resource/ResourceProfileBuilder.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/org/apache/spark/resource/ResourceProfileBuilder.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/org/apache/spark/resource/ResourceProfileBuilder.scala
Outdated
Show resolved
Hide resolved
Thanks for all the feedback. I've updated PR to include only 2 API changes(Seq -> Array and build -> build()) as @tgravescs agreed. And also filed follow-up JIRAs: SPARK-34460, SPARK-34461 Please take another look, thanks! |
Kubernetes integration test starting |
Kubernetes integration test status success |
Test build #135219 has finished for PR 31496 at commit
|
can we please rename pr and Jira and update the description. It would be good for jira to have description as well. |
core/src/main/scala/org/apache/spark/resource/ResourceProfileBuilder.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/org/apache/spark/resource/ResourceProfileBuilder.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/org/apache/spark/resource/ResourceProfileBuilder.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/org/apache/spark/resource/ResourceProfileBuilder.scala
Outdated
Show resolved
Hide resolved
core/src/main/scala/org/apache/spark/resource/TaskResourceRequest.scala
Outdated
Show resolved
Hide resolved
Thanks @tgravescs I have updated both PR and JIRA. |
Kubernetes integration test starting |
Test build #135246 has finished for PR 31496 at commit
|
Kubernetes integration test status failure |
@tgravescs and @holdenk, I plan to cut the RC as soon as possible (after the blocker #31550 is merged), but it seems like this PR includes two small changes that might matter in compatibility:
The changes look pretty fine to me, and I would like to merge this soon. I would appreciate if you guys take another look when you guys fine some time :-). |
There is also marking ResourceAllocator as private[spark] - everyone is OK with that, to be clear? |
yes I think marking ResourceAllocator as private is fine |
ResourceAllocator is mistakenly exposed previously. And there's no way to plug-in a custom ResourceAllocator into Spark. So it should be fine. |
OK sounds good to merge for 3.1 before the RC? I'll do so if someone doesn't beat me to it. |
core/src/main/scala/org/apache/spark/resource/ResourceProfile.scala
Outdated
Show resolved
Hide resolved
* Return all supported Spark built-in executor resources, custom resources like GPUs/FPGAs | ||
* are excluded. | ||
*/ | ||
def allSupportedExecutorResources: Seq[String] = _allSupportedExecutorResources |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we just def allSupportedExecutorResources: Array[String] = Array(CORES, MEMORY, OVERHEAD_MEM, PYSPARK_MEM, OFFHEAP_MEM)
for both cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, this also looks ok to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see, this also looks ok to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks fine to me ... hope you are ok with it @tgravescs
Kubernetes integration test starting |
Kubernetes integration test status success |
Test build #135290 has finished for PR 31496 at commit
|
Test build #135300 has finished for PR 31496 at commit
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I will wait for @tgravescs's input at #31496 (comment) (I am going to cut RC on the first working day from now on).
@tgravescs, I will merge this one I guess we'd be all fine with #31496 (comment) but will cut the RC in the next working day just in case you have a different thought. |
Merged to master and branch-3.1. |
### What changes were proposed in this pull request? This PR adds missing docs for ResourceProfile related APIs. Besides, it includes a few minor changes on API: * ResourceProfileBuilder.build -> ResourceProfileBuilder.builder() * Provides java specific API `allSupportedExecutorResourcesJList` * private `ResourceAllocator` since it was mistakenly exposed previously ### Why are the changes needed? Add missing API docs ### Does this PR introduce _any_ user-facing change? No, as Apache Spark 3.1 hasn't officially released. ### How was this patch tested? Updated unit tests due to the signature change of `build()`. Closes #31496 from Ngone51/resource-profile-api-cleanup. Authored-by: yi.wu <yi.wu@databricks.com> Signed-off-by: HyukjinKwon <gurwls223@apache.org> (cherry picked from commit 546d2eb) Signed-off-by: HyukjinKwon <gurwls223@apache.org>
Thanks all!! |
What changes were proposed in this pull request?
This PR adds missing docs for ResourceProfile related APIs. Besides, it includes a few minor changes on API:
allSupportedExecutorResourcesJList
ResourceAllocator
since it was mistakenly exposed previouslyWhy are the changes needed?
Add missing API docs
Does this PR introduce any user-facing change?
No, as Apache Spark 3.1 hasn't officially released.
How was this patch tested?
Updated unit tests due to the signature change of
build()
.