-
Notifications
You must be signed in to change notification settings - Fork 153
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
[#1629] fix(operator): ShuffleServer cannot be deleted even though there are no more application. #1630
Conversation
…gh there are no more application.
@advancedxy @wangao1236 Could you take a look at this pull request? |
In fact, both prom and json metrics may produce NaN. I'm only describing a situation where the webhook cannot handle NaN when parsing json metrics. We have two way to solve it. |
Hmm, in which case, a |
@@ -163,7 +164,7 @@ type MetricItem struct { | |||
Name string `json:"name"` | |||
LabelNames []string `json:"labelNames"` | |||
LabelValues []string `json:"labelValues"` | |||
Value float32 `json:"value"` | |||
Value interface{} `json:"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.
I don't think we should use interface{}
here. You can define a special type to custom json serialization and deserialization, such as https://stackoverflow.com/a/74179639/1730663
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!
In general, NaN is returned when there are not enough samples! |
OK, good to know. |
How is the progress here? @zhengchenyu |
It is OK for review? We are eager to apply this patch. @zhengchenyu @advancedxy |
I will take a look tonight(in Beijing time). |
Do we support Dashboard? |
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.
Generally lgtm, except one minor comment.
type JSONFloat float64 | ||
|
||
// UnmarshalJSON return the parsed JSONFloat | ||
func (j *JSONFloat) UnmarshalJSON(v []byte) error { |
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.
To be symmetric, would you mind to add the MarshalJSON
method 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.
Hmm, MarshalJSON is not used here. The metric is generated by shuffle server. Even if I unify the format, the output format of shuffle server is not affected.
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.
Yeah, I know MarshalJson
is not used here right now. But it might be used in the operator in the future for various reasons. It would be surprise or cause response failure in the operator when potentially serializing float with NaN. Since we already support deserializing float with NaN, I think it would nice to add serialize support to avoid any potential gochas.
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! Done!
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, pending CI passes.
Thanks @zhengchenyu .
Merged, thank you @zhengchenyu. |
) ### What changes were proposed in this pull request? When parsing json, handle special cases where the value might be NaN ### Why are the changes needed? Fix: #1629 ### Does this PR introduce _any_ user-facing change? No. ### How was this patch tested? test in real cluster and add unit test
What changes were proposed in this pull request?
When parsing json, handle special cases where the value might be NaN
Why are the changes needed?
Fix: #1629
Does this PR introduce any user-facing change?
No.
How was this patch tested?
test in real cluster and unit test