-
Notifications
You must be signed in to change notification settings - Fork 28.9k
[SPARK-16520] [WEBUI] Link executors to corresponding worker pages #14204
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 #62327 has finished for PR 14204 at commit
|
|
retest this please |
|
Test build #62329 has finished for PR 14204 at commit
|
|
I'll try to take a look at this tomorrow, but you're failing MiMa tests because you added a param to |
|
@ajbozarth Thanks for pointing out how to fix this. I'll try to fix it tomorrow. |
Merge the updates
|
Test build #62572 has finished for PR 14204 at commit
|
|
Test build #62575 has finished for PR 14204 at commit
|
|
From some quick testing and look through of your code I think this will be good, but you'll need to redo work it a bit to work with the new executors page that was just merged. The page is displayed using JQuery DataTables now. I'll take a more detailed look after you update this. |
# Conflicts: # core/src/main/scala/org/apache/spark/ui/exec/ExecutorsPage.scal1a
|
I have fixed the conflicts with #13670. |
|
Test build #62680 has finished for PR 14204 at commit
|
|
Updates to the code look good but you need to update the two failing tests still. I also created SPARK-16673 for the issues discussed in #13670 and am mentioning it since it affects this pr's original intended functionality. I am ok with saying this LGTM once you address the tests and letting SPARK-16673 cover adding the display condition. |
|
@nblintao I'm not sure if you're aware but you can actually run the same tests Jenkins runs locally before pushing, there's a build/test script dev/run-tests, thought I'd mention it since you're test fixes didn't fix everything |
|
Thanks for your reminding, @ajbozarth. I committed without testing locally this time because I thought it was a small fix and could pass the test. Unluckily, it still needs to be updated. |
|
You're good, not everyone knows about dev/run-tests so I thought I'd mention it |
|
Test build #62697 has finished for PR 14204 at commit
|
| val unpersistRdd = SparkListenerUnpersistRDD(12345) | ||
| val logUrlMap = Map("stderr" -> "mystderr", "stdout" -> "mystdout").toMap | ||
| val workerUrlMap = Map("url" -> "spark://[email protected]:32790", | ||
| "ui_url" -> "http://192.168.1.104:46445").toMap |
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 feel like these ip's should be something more generic, maybe check if there any other places in the test code that have strings with ip and ports that you could copy? Not an actual problem though since whats in the string only has to match the string below.
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.
Good idea. I've updated referring to the test cases in ClientSuite.scala. Thanks!
|
Test build #62700 has finished for PR 14204 at commit
|
|
Test build #62719 has finished for PR 14204 at commit
|
|
@nblintao I tried |
|
Test build #64583 has finished for PR 14204 at commit
|
|
Interesting, test again please. |
|
retest this, please |
|
Test build #64615 has finished for PR 14204 at commit
|
|
@nblintao Are you willing to rebase this and see if we can try to get it merged? |
|
Test build #70696 has finished for PR 14204 at commit
|
|
@ajbozarth I finally have a chance to rebase it in the winter break. Could you please have a look? Thanks! |
|
Test build #70697 has finished for PR 14204 at commit
|
ajbozarth
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.
Just one comment for now, I'll try to check this out and make sure it still looks good sometime this week.
| }, | ||
| { | ||
| "targets": [ 17 ], | ||
| "visible": workersExist(response) |
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.
We ran into an issue recently with columnDefs, it only runs on initial page load and doesn't catch changes on refresh. So for columns with non-static visibility you should add a line like this one below dt.column(15).visible(logsExist(response));
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. Thank you!
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.
Thanks, but this code is redundant now so it should be removed
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. Thanks!
|
Test build #70825 has finished for PR 14204 at commit
|
|
Test build #71557 has finished for PR 14204 at commit
|
|
So, if I understand this correctly, in non-standalone mode you'll have a completely empty column in the UI taking up space? Why is it important to collect the worker URL (not the UI address)? There's nothing users can do with that. I'm also not a fan of exposing things that are particular to one specific cluster manager in the REST API. I'd be a little more ok with this patch if it hid that information from the UI when it's not available. But in fact I don't really see much value in exposing that link. To me, it just clutters up the UI, so you might as well just have a link to the Master UI somewhere and tell users to find the worker there if they need it. |
That's one way of looking at it (although I haven't looked at that change). I took a quick look at the worker UI and didn't see anything interesting there. It has links to the executor's log files, but those already exist in the app UI. |
|
ok I agree. Originally, I thought it will be helpful to figure out the worker that an executor belongs to. But, if it does not provide very useful information. I am fine to drop it. |

What changes were proposed in this pull request?
Added a new column named "Worker" in the Executor Page of the web UI. For each executor (except the driver), it will provide a link to the web UI of the worker it belongs to.
This PR also retrieved worker URLs (besides worker UI URLs) from
ExecutorRunnertoExecutorsPage. This would help if we want to show then on the Executor Page later. (See #14204 (comment))Because the data of the URLs had not been retrieved to the executor UI (even not in the executor), passing them have the following effects:
ExecutorInfois changed. A new argument,workerUrl: Map[String, String], is added in the constructor of that class. But it is set toMap.emptyby default, so calling the old API still works. The executors for local and Mesos are stilling using call the old API.ExecutorInfois update.How was this patch tested?
Run Spark as a "local cluster" by
./bin/spark-shell --master=local-cluster[2,1,1024]. Then view the Executor Page on http://localhost:4040/executors/.You might need to clear the cache at the browser since some resources are changed. (especially
/static/executorspage-template.html.)See the column "Worker" on the right of the Executors Table. For each executor, click the hypertext link, jump to the web UI of the worker it belongs to.
Screenshot:
