-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-16194] Mesos Driver env vars #14167
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
Conversation
|
Test build #62201 has finished for PR 14167 at commit
|
|
Test build #62270 has finished for PR 14167 at commit
|
|
Error message from build: |
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.
Spark does not have a spark.driverEnv.[EnvironmentVariableName] while it has a spark.executorEnv.[EnvironmentVariableName] http://spark.apache.org/docs/latest/configuration.html.
From a UX experience and name consistency view i would expect something like that. The problem is that this pr only handles the mesos case so we cannot rename it to that name (unless we explicitly defined it in docs), also in client mode you do not need that so you will need to ignore it.
"spark.mesos.env." needs to be more specific like spark.mesos.driver.env but as i said spark.driverEnv seems more appropriate.
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.
From a UX experience and name consistency view i would expect something like that.
Yea I went back and forth on this. I'm fine with spark.mesos.driverEnv Does that work?
also in client mode you do not need that so you will need to ignore it.
Do you mean there needs to be some code change to ignore it? The only handling code is in the cluster dispatcher, so it's effectively ignored in client mode.
|
The build fails with: [error] /home/jenkins/workspace/SparkPullRequestBuilder@4/core/src/test/scala/org/apache/spark/scheduler/cluster/mesos/MesosClusterSchedulerSuite.scala:34: object Utils is not a member of package org.apache.spark.scheduler.cluster.mesos https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder/62270/consoleFull I reproduced it locally you are missing the Utils object. |
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.
Wild card imports should be avoided (unless you are importing more than 6 entities, or implicit methods) https://github.com/databricks/scala-style-guide. I think there are 5 (a bit picky here)...
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.
Removed the wildcard.
|
@skonto comments addressed. Please re-review. |
|
Note that I'll add docs once the code is 👍 |
|
Test build #62341 has finished for PR 14167 at commit
|
|
Test build #62340 has finished for PR 14167 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.
Pls fix indentation for method parameters (4 spaces, first parameter in a new line).
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.
fixed
|
LGTM other than minor style issues. I run our tests against it so refactoring is successful i guess. |
|
@skonto fixed the style issues @andrewor14 plz merge |
|
Test build #62391 has finished for PR 14167 at commit
|
|
@srowen Can we get a merge? |
|
I don't know anything about mesos, but I presume y'all are pretty expert. Unless anyone else with Mesos knowledge chimes in, and tests pass and all that, OK to merge. |
|
nit: From the code, it is |
|
LGTM. I agree with @viirya for the description. |
de75386 to
b9c396b
Compare
|
Updated the description and added docs. |
b9c396b to
1824d63
Compare
|
Test build #62629 has finished for PR 14167 at commit
|
|
Test build #62635 has finished for PR 14167 at commit
|
|
@andrewor14 @srowen pls merge |
|
Merged to master |
|
great thnx @srowen |
## What changes were proposed in this pull request?
New config var: spark.mesos.docker.containerizer={"mesos","docker" (default)}
This adds support for running docker containers via the Mesos unified containerizer: http://mesos.apache.org/documentation/latest/container-image/
The benefit is losing the dependency on `dockerd`, and all the costs which it incurs.
I've also updated the supported Mesos version to 0.28.2 for support of the required protobufs.
This is blocked on: #14167
## How was this patch tested?
- manually testing jobs submitted with both "mesos" and "docker" settings for the new config var.
- spark/mesos integration test suite
Author: Michael Gummelt <mgummelt@mesosphere.io>
Closes #14275 from mgummelt/unified-containerizer.
## What changes were proposed in this pull request? Added new configuration namespace: spark.mesos.env.* This allows a user submitting a job in cluster mode to set arbitrary environment variables on the driver. spark.mesos.driverEnv.KEY=VAL will result in the env var "KEY" being set to "VAL" I've also refactored the tests a bit so we can re-use code in MesosClusterScheduler. And I've refactored the command building logic in `buildDriverCommand`. Command builder values were very intertwined before, and now it's easier to determine exactly how each variable is set. ## How was this patch tested? unit tests Author: Michael Gummelt <mgummelt@mesosphere.io> Closes apache#14167 from mgummelt/driver-env-vars.
What changes were proposed in this pull request?
Added new configuration namespace: spark.mesos.env.*
This allows a user submitting a job in cluster mode to set arbitrary environment variables on the driver.
spark.mesos.driverEnv.KEY=VAL will result in the env var "KEY" being set to "VAL"
I've also refactored the tests a bit so we can re-use code in MesosClusterScheduler.
And I've refactored the command building logic in
buildDriverCommand. Command builder values were very intertwined before, and now it's easier to determine exactly how each variable is set.How was this patch tested?
unit tests