-
Notifications
You must be signed in to change notification settings - Fork 28.9k
[SPARK-19567][CORE][SCHEDULER] Support some Schedulable variables immutability and access #16905
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
srowen
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.
I wonder if @squito or @kayousterhout has thoughts on these tweaks? I do like cleaning up and tightening the internal impl if there isn't a downside.
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.
This should be in a companion object, but really, maybe not worth 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.
Maintaining these messages with the various options is error-prone. Can you just use its .values and print that?
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're not likely to add or remove SchedulingModes with any frequency, if at all, so this isn't likely to cause much opportunity for error -- but I agree with the principle that extracting from .values is a better approach.
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.
SchedulingMode possible values are FIFO, FAIR and NONE but NONE is unsupported value. I agree to support for potential values and it can be achieved by adding following logic to SchedulingMode object and can be used required places(2 times here and 1 time at Pool)
def getSupportedValuesAsString(): String = values.filter(_ != NONE).mkString(", ") SchedulingMode.getSupportedValuesAsString() // returns FIFO, FAIR
WDYT?
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.
NONE is only used in tests, and doesn't really need to be used there -- see the commit in my repo that I pointed you to earlier. Technically, removing NONE is a change in the public interface, but the docs say that only FAIR and FIFO are allowed (http://spark.apache.org/docs/latest/job-scheduling.html#configuring-pool-properties), and trying to use NONE will lead you to the "unsupported" failure, so we probably can get rid of 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.
Yep, TaskSetManager also uses NONE to override schedulingMode (from parent Schedulable trait). However, it does not use schedulingMode. I think if NONE is removed, then FIFO will be used as the default value(e.g. TaskManager), right?
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.
These appear to be pretty much redundant then? if they're just set once to another existing variable's value?
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.
Pool extends Schedulable trait and needs to override weight. It is also used for taskToWeightRatio calculation at FairSchedulingAlgorithm level.
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.
This is duplicated
|
@srowen These refactorings of unnecessary vars to vals is something that we've noted in the discussions of a few other PRs as something that could and probably should be done in a separate PR (i.e. this one). @erenavsarogullari There is another such refactoring that can be rolled into this PR. See the changes that I've made to |
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'd really rather not see this kind of change. Other than the missing string-interpolation s in msg, the prior code was at least as good (and arguably better) than the new style, and making such an inconsequential style change just adds complication to future investigations of the git history.
|
Thanks @markhamstra and @srowen for the quick reviews. |
|
Hi All, @markhamstra, if it is suitable, i plan to address removing SchedulingMode.NONE via separated PR. In the light of this, the following new added unit test cases(using
WDYT? |
|
Hi @markhamstra, |
|
ok to test |
|
Thanks @markhamstra. |
|
If Jenkins is listening to me, that should have allowed you to trigger test for this PR. test this please |
|
Thanks @markhamstra. I encounter the same problem in my every PR and tech-ops team helps to trigger Jenkins. Problem may be related with Github Jenkins PR Builder plugin. Also it still looks not triggered. |
|
Jenkins test this please |
|
@erenavsarogullari the reason this was happening on past PRs is that Imran and I weren't on the Jenkins whitelist (which neither of us realized -- and has since been fixed). I think Mark is on the whitelist so this is probably a transient issue... we'll see if my triggering works. |
|
Test build #73232 has finished for PR 16905 at commit
|
|
@shaneknapp is @markhamstra on the Jenkins whitelist? Wanted to double check since his attempt to trigger the build above didn't work |
|
nope, he's not in the admin list. i'll add him now. |
|
Awesome thanks Shane! |
|
Thanks, Shane & Kay! |
|
Many thanks @kayousterhout and @markhamstra. |
|
Jenkins this is OK to test |
|
Thanks @kayousterhout. However, it still looks not triggered. |
|
retest this please |
|
Test build #73299 has finished for PR 16905 at commit
|
|
Hi @markhamstra, @kayousterhout and @squito |
squito
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.
lgtm
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.
one quick comment here if Imran didn't already merge: can you un-do these changes to add private? It's not useful / necessary to make test classes private (they're already hidden by the build), and this change will make git blames more confusing in the future.
|
Thanks @kayousterhout and @squito for review this ;) |
|
Jenkins test this please |
|
Thanks again @kayousterhout and @squito. |
|
Jenkins retest this please |
|
Test build #74620 has finished for PR 16905 at commit
|
|
Test build #74629 has finished for PR 16905 at commit
|
|
reopened https://issues.apache.org/jira/browse/SPARK-7420 for the failure Jenkins, retest this please |
|
Thanks again @kayousterhout and @squito ;) |
|
@shaneknapp I had to trigger jenkins manually via spark-prs. Every once in a while I encounter a pr for which tests are never triggered via comments. Its pretty rare, so its not a big deal, but I thought I'd point you at this in case you want to take a look. |
|
Test build #3600 has finished for PR 16905 at commit
|
|
Test build #3601 has finished for PR 16905 at commit
|
|
Hi @squito, I think jenkins can be triggered again. Last unrelated build - UT issue looks fixed(https://issues.apache.org/jira/browse/SPARK-19988) Thanks in advance ;) |
|
Jenkins, this is ok to test |
|
Jenkins test this please |
|
Jenkins add to whitelist |
|
Test build #75070 has finished for PR 16905 at commit
|
|
Test build #75072 has finished for PR 16905 at commit
|
|
LGTM merged into master |
What changes were proposed in this pull request?
Some
SchedulableEntities(PoolandTaskSetManager) variables need refactoring for immutability and access modifiers levels as follows:vartoval(if there is no requirement): This is important to support immutability as much as possible.Pool:weight,minShare,priority,nameandtaskSetSchedulingAlgorithm.vars access needs to be restricted from other parts of codebase to prevent potential side effects.TaskSetManager:tasksSuccessful,totalResultSize,calculatedTasksetc...This PR is related with #15604 and has been created seperatedly to keep patch content as isolated and to help the reviewers.
How was this patch tested?
Added new UTs and existing UT coverage.