-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-27959][YARN] Change YARN resource configs to use .amount #24989
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-27959][YARN] Change YARN resource configs to use .amount #24989
Conversation
|
cc @szilard-nemeth I think you originally add these configs |
|
Test build #106977 has finished for PR 24989 at commit
|
|
Test build #107023 has finished for PR 24989 at commit
|
|
@vanzin I think you reviewed first change for the resources, you ok with this approach |
vanzin
left a comment
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 ok.
I was thinking a little about what would happen if a new resource is supported by the scheduler (the user would have to set it in both configs, as your comment suggests) and whether that could be simplified somehow, but that sounds like a separate problem.
resource-managers/yarn/src/main/scala/org/apache/spark/deploy/yarn/ResourceRequestHelper.scala
Outdated
Show resolved
Hide resolved
...e-managers/yarn/src/test/scala/org/apache/spark/deploy/yarn/ResourceRequestHelperSuite.scala
Outdated
Show resolved
Hide resolved
|
yeah its not ideal to have it hardcoded and then have to specify 2 configs for those. Thought about coming up with some sort of mapping but figured for now we can do this and come up with something else later. |
|
Test build #107738 has finished for PR 24989 at commit
|
|
Shall we test this with |
|
retest this please |
|
Test build #107745 has finished for PR 24989 at commit
|
|
Merging to master. |
attilapiros
left a comment
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.
Mostly NITs otherwise LGTM.
| private val AMOUNT_AND_UNIT_REGEX = "([0-9]+)([A-Za-z]*)".r | ||
| private val RESOURCE_INFO_CLASS = "org.apache.hadoop.yarn.api.records.ResourceInformation" | ||
| val YARN_GPU_RESOURCE_CONFIG = "yarn.io/gpu" | ||
| val YARN_FPGA_RESOURCE_CONFIG = "yarn.io/fpga" |
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.
Does it make sense to reuse ResourceUtils.GPU and ResourceUtils.FPGA here?
Like:
val YARN_GPU_RESOURCE_CONFIG = "yarn.io/$GPU"
val YARN_FPGA_RESOURCE_CONFIG = "yarn.io/$FPGA"For suggesting using as close mapping as possible between the Spark config keys and YARN resource config keys (now and the future).
I know your PR does not touched this part:
spark/resource-managers/yarn/src/main/scala/org/apache/spark/deploy/yarn/ResourceRequestHelper.scala
Lines 111 to 118 in 6e86ab9
| (ResourceID(SPARK_EXECUTOR_PREFIX, "fpga").amountConf, | |
| s"${YARN_EXECUTOR_RESOURCE_TYPES_PREFIX}${YARN_FPGA_RESOURCE_CONFIG}"), | |
| (ResourceID(SPARK_DRIVER_PREFIX, "fpga").amountConf, | |
| s"${YARN_DRIVER_RESOURCE_TYPES_PREFIX}${YARN_FPGA_RESOURCE_CONFIG}"), | |
| (ResourceID(SPARK_EXECUTOR_PREFIX, "gpu").amountConf, | |
| s"${YARN_EXECUTOR_RESOURCE_TYPES_PREFIX}${YARN_GPU_RESOURCE_CONFIG}"), | |
| (ResourceID(SPARK_DRIVER_PREFIX, "gpu").amountConf, | |
| s"${YARN_DRIVER_RESOURCE_TYPES_PREFIX}${YARN_GPU_RESOURCE_CONFIG}")) |
But at that place using the right constant ($GPU or $FPGA) instead of the string literal is reasonable.
|
|
||
| private[yarn] def getYarnResourcesAndAmounts( | ||
| sparkConf: SparkConf, | ||
| componentName: String): Map[String, String] = { |
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.
Nit: in getYarnResourcesFromSparkResources the second parameter is the SparkConf what about taking the componentName (prefix) to the first place here too.
|
It is already closed. Anyway if you think my comments useful even I can do this small changes in a follow-up or in a minor PR. |
## What changes were proposed in this pull request?
we are adding in generic resource support into spark where we have suffix for the amount of the resource so that we could support other configs.
Spark on yarn already had added configs to request resources via the configs spark.yarn.{executor/driver/am}.resource=<some amount>, where the <some amount> is value and unit together. We should change those configs to have a `.amount` suffix on them to match the spark configs and to allow future configs to be more easily added. YARN itself already supports tags and attributes so if we want the user to be able to pass those from spark at some point having a suffix makes sense. it would allow for a spark.yarn.{executor/driver/am}.resource.{resource}.tag= type config.
## How was this patch tested?
Tested via unit tests and manually on a yarn 3.x cluster with GPU resources configured on.
Closes apache#24989 from tgravescs/SPARK-27959-yarn-resourceconfigs.
Authored-by: Thomas Graves <[email protected]>
Signed-off-by: Marcelo Vanzin <[email protected]>
What changes were proposed in this pull request?
we are adding in generic resource support into spark where we have suffix for the amount of the resource so that we could support other configs.
Spark on yarn already had added configs to request resources via the configs spark.yarn.{executor/driver/am}.resource=, where the is value and unit together. We should change those configs to have a
.amountsuffix on them to match the spark configs and to allow future configs to be more easily added. YARN itself already supports tags and attributes so if we want the user to be able to pass those from spark at some point having a suffix makes sense. it would allow for a spark.yarn.{executor/driver/am}.resource.{resource}.tag= type config.How was this patch tested?
Tested via unit tests and manually on a yarn 3.x cluster with GPU resources configured on.