-
Notifications
You must be signed in to change notification settings - Fork 150
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
CPU limitations #774
CPU limitations #774
Conversation
@vitaliy-guliy we have gh action that automatically build and push the content to surge,sh. https://pr-check-774-alpine-che-plugin-registry.surge.sh/ |
I haven't noticed, that we have this action. Thanks. |
che-theia-plugins.yaml
Outdated
@@ -1,22 +1,30 @@ | |||
version: 1.0.0 | |||
plugins: | |||
|
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.
@vitaliy-guliy maybe it makes sense to apply some formatter for this file, for example https://jsonformatter.org/yaml-formatter, like it was done for https://github.com/eclipse/che-plugin-registry/blob/master/che-plugins.yaml
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 intentionally added empty lines to separate the plugins each other. Also the formatter removes comments with plugin ID.
The links to the extensions become written in two lines, instead of one line.
extensions:
- >-
https://github.com/microsoft/vscode-pull-request-github/releases/download/0.20.0/vscode-pull-request-github-0.20.0.vsix
Anything else stay unchanged. Let's leave it as it is at the moment. 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.
I would prefer it if the comments with the plugin ID are removed, and the che-theia-plugins.yaml
file stays in the same format as the others che-*.yaml
files. The ID
fields are based on the publisher field from the upstream package.json
files, which can change at any time. Writing the IDs here means that they could be out of date.
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.
@ericwill the file is formatted by https://jsonformatter.org/yaml-formatter as @svor mentioed
@svor I think it's related to permissions issue on PVC. You probably got an ephemeral workspace when you tried to created workspace from same devfile on che.openshift.io. That's why it's working. |
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 expected to define such a big CPU request? I though the idea would be defining CPU request fairly low, and currently, it is not clear why 0.2 is considered to be the fair request
There was no special idea to set 0.2. Taking a look at cpu limitation for jwtproxy, I see that 20m would be enough. WDYT? |
@vitaliy-guliy jwt proxy request is you can follow up on the verification discussion in the PR e.g. - eclipse-che/che#18551 (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.
CPU requests are very high
updated |
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 for me
@ibuziuk it seems both CPU request and limitation were not applied to the plugin container eclipse-che/che#18730 |
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 looks like a good start, but I'm personally missing the justification / metrics for the following request & limits which is set identical to every plugin:
cpuLimit: 500m
cpuRequest: 30m
Let's start with a higher bound and we can tighten it with each iteration. From my side I'm fine with the PR, if you don't have any other concerns then let's merge 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.
Let's start with a higher bound and we can tighten it with each iteration. From my side I'm fine with the PR, if you don't have any other concerns then let's merge it.
agree, @vitaliy-guliy could you please also update the eclipse-che/che#16685 with details
@l0rd WDYT about backporing this also to 7.24.x?
Have those changes been tested on openshift dev cluster (or cluster bot) and RHPDS? |
No, I will test them today on both instances you described. |
@l0rd all the devfiles have been tested on RHPDS and openshift dev cluster. Everything is working as expected. |
Thanks @vitaliy-guliy. You have tested on minikube too right? |
It's the first what I did. On minikube I've tested not all the devfiles, but node, java, dotnet worked well. One thing is java language server works a bit slowly even locally. So, I will add it a bit more CPU. |
@benoitf it seems happy path tests don't work for all the PRs. WDYT if we merge this PR as it is? |
@vitaliy-guliy it's fine from my POV, please resolve conflicts and merge when you are ready |
Codecov Report
@@ Coverage Diff @@
## master #774 +/- ##
=======================================
Coverage 91.44% 91.44%
=======================================
Files 38 38
Lines 923 923
Branches 105 105
=======================================
Hits 844 844
Misses 79 79 Continue to review full report at Codecov.
|
Signed-off-by: Vitaliy Gulyy <vgulyy@redhat.com>
0cdaa89
to
07ca325
Compare
Signed-off-by: Vitaliy Gulyy vgulyy@redhat.com
What does this PR do?
Adds CPU requests/limits to all the plugin sidecars.
What issues does this PR fix or reference?
eclipse-che/che#16685
How to test this PR?
Option 1
Build plugin registry by hands and deploy local Che.
Steps to do:
quay.io
patch.yaml
to replace the default plugin registrypath.yaml
contentPlugins in local plugin registry must have resource limitations provided by this PR.
Option 2
Use devfiles to test some stacks.
All the devfiles are using pre-built plugin registry from this PR.
Option 3
Use factories to test changes on che.openshift.io using devfiles from Option 2.
Test summary
https://docs.google.com/spreadsheets/d/1aktG-vJM1Mxqb77pkWQpiiBbXudzdByMwKG1toION8Q/edit#gid=0
PR Checklist
As the author of this Pull Request I made sure that:
What issues does this PR fix or reference
andHow to test this PR
completedReviewers
Reviewers, please comment how you tested the PR when approving it.