-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-16637] Unified containerizer #14275
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
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.
Added Serializable so that SparkConf can be persisted to ZK
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.
Is SparkConf persisted by a MesosClusterPersistenceEngineFactory instance or somewhere else?
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.
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.
Interesting, this wasn't already serializable eh. Normally that might be a significant choice but this just contains a concurrent map, so seems OK. (And this field avroNamespace which should have been in the object)
|
Test build #62569 has finished for PR 14275 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.
I think this should be: spark.mesos.containerizer. Otherwise its confusing. I guess you mean what is the containerizer for the docker image.
|
I tested it against our test suite it works fine. Have you tested it with an image: spark.mesos.executor.docker.image? Do you have a sample image? I would like to test it... we could add it to our suite as well... |
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.
Bridge mode is not supported right? Why we need that?
I read in the docs spark.mesos.executor.docker.portmaps is used for that. I think docs need update.
There was a question here in the user list (we should answer i think):
https://mail-archives.apache.org/mod_mbox/spark-user/201604.mbox/%3CCAKOFcwroULK_b2RajeAO3v_DZ2qS8uN86HekxUJejQA4=FspSw@mail.gmail.com%3E
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.
Yea, this is effectively dead. I'll leave it to a future PR to remove.
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.
Ok cool we clarified that, there is a lot of confusion out there. How about the image is there one i can use to test it quickly? I really want to do that before reporting its good.
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.
You can use ours: https://github.com/mesosphere/universe/blob/version-3.x/repo/packages/S/spark/14/resource.json#L5
The Spark dist is located at /opt/spark/dist
I've also already tested this manually.
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.
👍 ok just a quick check i will do (a ritual for me) and will be fine from my side and then i will invite the committers for inspection and merge (tom).
e0fe773 to
53d01ec
Compare
|
Test build #62684 has finished for PR 14275 at commit
|
|
@skonto rebased and ready for re-review |
|
Test build #62685 has finished for PR 14275 at commit
|
|
Test build #62686 has finished for PR 14275 at commit
|
|
Test "supports spark.mesos.driverEnv.*" fails. The reason is that the map there contains ".TEST_ENV", the dot is the issue. |
|
good eye. fixed. |
085e228 to
5bb1a35
Compare
|
Test build #62694 has finished for PR 14275 at commit
|
|
Test build #62695 has finished for PR 14275 at commit
|
|
@srowen Could you pls check and merge? |
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.
Why can't this be val BTW?
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.
probably because its not used outside the class from what i recall. There is no reason why it cant bw.
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'm probably missing your point but would that affect val? it might be private too but this change just removes val.
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.
Removing val means schedulerProperties is not saved as a field of the class. It's just used during construction. I could also make this private val if that's more standard in this project.
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.
That was my point too above. No public getters generated if no val is used and this can be justified if the field is not used in general outside of the class. I would choose for example private val if I need access to the private val of an instance of a class T within some other instance of T. The latter is not possible if I just use the field without val.
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.
Oh right, this is what causes it to become a field. Yeah I suspect lots and lots of things in the code should not even be val.
|
@srowen ready for re-review |
|
Test build #62735 has finished for PR 14275 at commit
|
|
LGTM. |
|
OK, looks good to me too though I don't really know about Mesos. |
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 have a sensible message/exception when we pass in a unknown containerizer?
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.
done
|
Looks like one more last comment, and needs a rebase after #13051 |
|
Test build #62840 has finished for PR 14275 at commit
|
|
Test build #62841 has finished for PR 14275 at commit
|
4a0af2e to
82359ba
Compare
|
Test build #62937 has finished for PR 14275 at commit
|
|
Test build #62939 has finished for PR 14275 at commit
|
|
@srowen Could you please merge? |
|
Merged to master |
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?