-
Notifications
You must be signed in to change notification settings - Fork 2.8k
ZEPPELIN-1692: Ability to access Spark jobs UI from the paragraph #1663
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
Closed
Closed
Changes from all commits
Commits
Show all changes
22 commits
Select commit
Hold shift + click to select a range
f16422f
Ability to view spark job urls in each paragraph
karuppayya 9b3a3e2
Fix checkstyle
karuppayya 3d9a573
Fix NPE and some refactoring
karuppayya e2cd4db
Fix NPE in tests
karuppayya 7383c0a
Address review comments
25379aa
Clear job urls when we clear output
717eedf
Add tests , refactor
1a45284
Fix test
d4e54e8
Address review feedbacks
karuppayya 42d92ac
Fix test
karuppayya b837c6c
Fix incorrect variable used
fc44d9b
Address review comments
09fc0e2
Fix compilation
19513a6
Send para runtimeinfos via websocker, but dont persist in json
87214a7
Fix incorrect rebase
d27221d
Adding license header
ed4685c
Fix tooltip
890107d
Fix test - tryout
732b0a4
Fix test
8e2cd85
tryout: fix selenium tests based on moons suggstion
d7eb3b6
Fix paragraph.js
4253d0b
Fix bad rebase
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
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.
#1637 also exposed one of method of RemoteEventClient to interpreter. But little different way.
#1637 created new class
RemoteWorksControllerto wrap RemoveEventClient.https://github.com/apache/zeppelin/pull/1637/files#diff-5f11952b2fbf4e41e273df20c409ec4b
This PR's approach and #1637 's approach is basically the same, but in the future refactoring, i think we need to decide either a) create new class for every feature exported from RemoveEventClient (like RemoteWorksController), or b) create a common wrapper class RemoteEventClientWrapper and export all necessary methods from it.
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.
@Leemoonsoo Regarding the refactoring, I not only mean
RemoveEventClient, but also other interpreter related components. LikeInterpreterFactory,InterpreterSetting,InterpreterGroup,RemoteInterpreterand etc. I just feel the boundary and responsibility of these classes/components is not clear for now.InterpreterFactoryis too complicated and should delegate many work toInterpreterSetting. And currently there's no single component to manage the lifecycle of interpreters. I know refactoring is a little risky and may affect functions. So I think maybe we put this as part of 0.8. If you think this is feasible and necessary. I can write a more detailed document and gather more feedback from communities. What do you think ?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.
The reason i mentioned especially
RemoveEventClientis because its part of Interpreter development API and we want to minimize API change on every release. (doesn't mean this PR has to take care)Agree, we can reactor overall interpreter layer once we freeze 0.7.