Skip to content
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

[ws-daemon] Prevent divide by zero error #12315

Merged
merged 3 commits into from
Aug 24, 2022

Conversation

Furisto
Copy link
Member

@Furisto Furisto commented Aug 23, 2022

Description

Prevent divide by zero error

Related Issue(s)

Fixes #12295

Release Notes

Prevent divide by zero error in workspace info service

Werft options:

  • /werft with-preview

@Furisto Furisto requested review from a team August 23, 2022 17:07
@github-actions github-actions bot added team: webapp Issue belongs to the WebApp team team: workspace Issue belongs to the Workspace team labels Aug 23, 2022
@Furisto Furisto removed size/XS team: webapp Issue belongs to the WebApp team labels Aug 23, 2022
@kylos101
Copy link
Contributor

👋 @Furisto hey there, as this already has an issue, we can 1) relate the PR to the issue and 2) relate the issue to the project (I just did those things). Thanks for the quick turnaround!

Copy link
Contributor

@kylos101 kylos101 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Furisto can you share how to test? It looks like the code path will exit here now, instead of trying to do the division here. 👍

I ask because I'm not sure what scenario would have caused os.ReadFile(path) to return an error in the first place.

@Furisto
Copy link
Member Author

Furisto commented Aug 23, 2022

@kylos101 I am not sure how exactly this happened either, but returning an error is better than a runtime panic and the error message could help us find out why it is happening.

@werft-gitpod-dev-com
Copy link

started the job as gitpod-build-furisto-ws-daemon-panics-with-integer-12295.1 because the annotations in the pull request description changed
(with .werft/ from main)

@werft-gitpod-dev-com
Copy link

started the job as gitpod-build-furisto-ws-daemon-panics-with-integer-12295.3 because the annotations in the pull request description changed
(with .werft/ from main)

@utam0k utam0k force-pushed the furisto/ws-daemon-panics-with-integer-12295 branch from 2dff4a4 to e15d433 Compare August 24, 2022 02:25
@werft-gitpod-dev-com
Copy link

started the job as gitpod-build-furisto-ws-daemon-panics-with-integer-12295.5 because the annotations in the pull request description changed
(with .werft/ from main)

@utam0k
Copy link
Contributor

utam0k commented Aug 24, 2022

@Furisto I put a commit into your branch for more accurate value handling

Signed-off-by: utam0k <k0ma@utam0k.jp>
@utam0k utam0k force-pushed the furisto/ws-daemon-panics-with-integer-12295 branch from e15d433 to d3d9ce6 Compare August 24, 2022 03:59
@werft-gitpod-dev-com
Copy link

started the job as gitpod-build-furisto-ws-daemon-panics-with-integer-12295.7 because the annotations in the pull request description changed
(with .werft/ from main)

@roboquat roboquat added size/M and removed size/XS labels Aug 24, 2022
Copy link
Contributor

@jenting jenting left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice!

For next, we need to unit test iws.go with the mock function.

@roboquat roboquat merged commit a35deeb into main Aug 24, 2022
@roboquat roboquat deleted the furisto/ws-daemon-panics-with-integer-12295 branch August 24, 2022 11:22
@roboquat roboquat added the deployed: workspace Workspace team change is running in production label Sep 7, 2022
@roboquat roboquat added the deployed Change is completely running in production label Sep 7, 2022
return nil, err
}

// if no cpu limit has been specified, use the number of cores
var limit uint64
if quota == math.MaxUint64 {
// TODO(toru): we have to check a parent cgroup instead of a host resources
Copy link
Member

@aledbf aledbf Sep 15, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@utam0k this logic is wrong. What we should do here is to set the lower limit of the class, and if that value is not set, use the cpuLimits value from ws-daemon.

@utam0k please revert this commit and implement what I am suggesting. This change breaks the CPU limiting when we cannot read cpu.Max. Please also include details about this change is being tested.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@aledbf Thanks for your review. I have a question. this method is used for gp top, right? I think this method doesn't relate to the CPU limiting. Please let me know if I am wrong.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method is not involved in cpu limiting, it is only used for the endpoint that gp top/supervisor is calling to get resource information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployed: workspace Workspace team change is running in production deployed Change is completely running in production release-note size/M team: workspace Issue belongs to the Workspace team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[ws-daemon] panics with integer divide by zero err
6 participants