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

CPU limitations #774

Merged
merged 1 commit into from
Feb 2, 2021
Merged

CPU limitations #774

merged 1 commit into from
Feb 2, 2021

Conversation

vitaliy-guliy
Copy link
Contributor

@vitaliy-guliy vitaliy-guliy commented Dec 17, 2020

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:

  • build the plugin registry from this branch
$ ./build.sh
  • upload the plugin registry image to your account at quay.io
$ docker tag quay.io/eclipse/che-plugin-registry:nightly quay.io/vgulyy/che-plugin-registry:resource-limit
$ docker push quay.io/vgulyy/che-plugin-registry:resource-limit
  • deploy local Che with applying following patch.yaml to replace the default plugin registry
$ chectl server:start --platform=minikube --che-operator-cr-patch-yaml patch.yaml

path.yaml content

spec:
  server:
    pluginRegistryImage: quay.io/vgulyy/che-plugin-registry:resource-limit
  • create any workspace and test how plugins work

Plugins 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:

Reviewers

Reviewers, please comment how you tested the PR when approving it.

@vitaliy-guliy vitaliy-guliy marked this pull request as ready for review December 24, 2020 23:42
@sunix
Copy link
Contributor

sunix commented Dec 28, 2020

@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/
Alternatively if the PR is not created yet, you can use the devfile to push on surge.sh

@vitaliy-guliy
Copy link
Contributor Author

@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/
Alternatively if the PR is not created yet, you can use the devfile to push on surge.sh

I haven't noticed, that we have this action. Thanks.
Will rework the links for workspace creation.

@@ -1,22 +1,30 @@
version: 1.0.0
plugins:

Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Contributor

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.

Copy link
Contributor Author

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

che-theia-plugins.yaml Outdated Show resolved Hide resolved
che-theia-plugins.yaml Outdated Show resolved Hide resolved
@svor
Copy link
Contributor

svor commented Dec 28, 2020

I don't see how it is related to this PR but nodejs-mongo stack from your list of factories doesn't work, the command to run the application is failed:
screenshot-che openshift io-2020 12 28-15_56_05
I tried to create a workspace from existing devfile registry on che.openshift.io and the command works for that ws.

@vitaliy-guliy
Copy link
Contributor Author

@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.

@svor
Copy link
Contributor

svor commented Dec 28, 2020

yes, it was the reason. Tested nodejs-mongo devfile and everything worked without problems
screenshot-che openshift io-2020 12 28-16_48_33

Copy link
Member

@ibuziuk ibuziuk left a 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

@vitaliy-guliy
Copy link
Contributor Author

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?

@ibuziuk
Copy link
Member

ibuziuk commented Dec 30, 2020

@vitaliy-guliy jwt proxy request is 0.03 not 0.2 - https://github.com/eclipse/che/pull/18551/files#diff-deca31b9cca47d5b0356dd75fc0fd0c8cb980f3aa029da27b475bdbb37353eb0R611

you can follow up on the verification discussion in the PR e.g. - eclipse-che/che#18551 (comment)

Copy link
Member

@ibuziuk ibuziuk left a 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

@vitaliy-guliy
Copy link
Contributor Author

CPU requests are very high

updated

Copy link
Contributor

@svor svor left a comment

Choose a reason for hiding this comment

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

OK for me

@vitaliy-guliy
Copy link
Contributor Author

@ibuziuk it seems both CPU request and limitation were not applied to the plugin container eclipse-che/che#18730

@vitaliy-guliy vitaliy-guliy requested a review from ibuziuk January 11, 2021 11:03
Copy link
Member

@ibuziuk ibuziuk left a 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

@ericwill
Copy link
Contributor

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.

Copy link
Member

@ibuziuk ibuziuk left a 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?

@l0rd
Copy link
Contributor

l0rd commented Jan 13, 2021

Have those changes been tested on openshift dev cluster (or cluster bot) and RHPDS?

@vitaliy-guliy
Copy link
Contributor Author

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.
On hosted Che everything is working fine.

@vitaliy-guliy
Copy link
Contributor Author

@l0rd all the devfiles have been tested on RHPDS and openshift dev cluster. Everything is working as expected.
I attached a spreadsheet to the PR description with testing results.

@l0rd
Copy link
Contributor

l0rd commented Jan 27, 2021

Thanks @vitaliy-guliy. You have tested on minikube too right?

@vitaliy-guliy
Copy link
Contributor Author

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.

@vitaliy-guliy
Copy link
Contributor Author

@benoitf it seems happy path tests don't work for all the PRs. WDYT if we merge this PR as it is?

@ericwill
Copy link
Contributor

ericwill commented Feb 1, 2021

@vitaliy-guliy it's fine from my POV, please resolve conflicts and merge when you are ready

@codecov
Copy link

codecov bot commented Feb 2, 2021

Codecov Report

Merging #774 (0cdaa89) into master (a87ebf3) will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           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.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 7ba6127...07ca325. Read the comment docs.

Signed-off-by: Vitaliy Gulyy <vgulyy@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants