-
Notifications
You must be signed in to change notification settings - Fork 29k
[SPARK-21353][CORE]add checkValue in spark.internal.config about how to correctly set configurations #18555
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
|
cc @cloud-fan , @srowen |
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 you also check for other configs in this file and add checkValues as much as possible? Thanks!
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,
please review it again.
thanks.
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 we can remove 's'.
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.
remove it.
thanks.
please review it again.
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.
ditto.
|
Please also update the PR description. Thanks! |
|
ok to test |
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.
boolean conf doesn't need checkValue...
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.
please review it again.
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 should also mention that, if no unit is given, e.g. 500, it means 500mb. We also need to update configuration.md for this conf.
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.
nvm, we should not mention that and always ask users to add unit.
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.
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.
ditto
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.
ditto
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.
check if >= 0?
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.
check if >= 0?
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.
It might be a bit out of place.
In org.apache.spark.ExecutorAllocationManagerSuite.scala
val conf2 = conf.clone().set("spark.dynamicAllocation.maxExecutors", "-1")
Why is this value set less than zero?
Not yet understood.
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 the same.
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.
ditto
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.
should be greater than 0
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.
ditto
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.
ditto
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.
ditto
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.
ditto
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.
ditto
|
Test build #79361 has finished for PR 18555 at commit
|
|
Test build #79364 has finished for PR 18555 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.
Actually Configuration like spark.dynamicAllocation.minExecutors already has check validation logics in the code where honors it (ExecutorAllocationManager). So probably checking here again makes duplication.
Also one limitation here for checking validation is that it could only verify the validity of single configuration, but for some confs like spark.dynamicAllocation.minExecutors they should be verified with other confs like spark.dynamicAllocation.minExecutors <= xxxx.initialExecutors <= xxx.maxExecutors.
jerryshao
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 think we should create a JIRA for this issue, it is not so minor I think.
Also as I mentioned before there exists the checking duplication here and the code uses 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.
IIUC, Should it here be Int.MaxValue / 1024?
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.
sorry .
have update it.
thanks.
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 it more accurate to use MiB instead of MB here? also please add WS like 0 MiB.
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.
Also 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.
Please unify this style to one for all the checks if possible, like _ > 0.
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.
Maybe we should let user to decide whether to bind to a privileged port. Taking an assumption here may potentially break some use cases.
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.
+1 on ^
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.
@jerryshao , @HyukjinKwon
Because of the same port control at startServiceOnPort, do we need to open it here?
def startServiceOnPort[T](
startPort: Int,
startService: Int => (T, Int),
conf: SparkConf,
serviceName: String = ""): (T, Int) = {
require(startPort == 0 || (1024 <= startPort && startPort < 65536),
"startPort should be between 1024 and 65535 (inclusive), or 0 for a random free port.")
...
}
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.
Ah, do you mean the check was already there and the current change just brings it ahead to make it fail fast? If so, that's fine.
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.
well, thanks!
|
Please open a JIRA for this PR |
|
We should also check for duplicated config check value logics in the code, but I think these could be addressed in a follow-up PR. |
|
Test build #79421 has finished for PR 18555 at commit
|
|
Test build #80117 has finished for PR 18555 at commit
|
|
Thanks! @heary-cao cc @jiangxb1987 Could you take a look to ensure no behavior change will be caused by this PR? |
jiangxb1987
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, thanks for the effort @heary-cao !
|
@jiangxb1987 |
46f1439 to
3135235
Compare
|
Test build #80540 has finished for PR 18555 at commit
|
|
cc @gatorsmile |
|
retest this please |
|
Test build #84786 has finished for PR 18555 at commit
|
3135235 to
cac5c03
Compare
|
Test build #86961 has finished for PR 18555 at commit
|
cac5c03 to
c213be6
Compare
|
Test build #87024 has finished for PR 18555 at commit
|
|
retest this please |
|
ok to test |
|
retest this please |
|
Seems #18555 (comment) is missed. |
|
Test build #87048 has finished for PR 18555 at commit
|
c213be6 to
a0efb41
Compare
|
Test build #87053 has finished for PR 18555 at commit
|
|
Hmm .. why not addressing #18555 (comment)? I think that comment makes sense. |
|
cc @HyukjinKwon, |
|
Seems fine. |
|
ok to test |
|
Test build #91602 has finished for PR 18555 at commit
|
What changes were proposed in this pull request?
Currently, some of the configuration parameters of spark.internal.config without adding checkValue function, which is incorrect, this PR will be add checkValue for the configuration parameters.
How was this patch tested?
existing test and add a new test case.