Possible to set CPU limits as well on the plugin containers?

[mjshashank]

The che-plugin.yml containing the plugin container and related specs does not seem to have a field for CPU limits while the same exists for Memory as memorylimit.

Is there a possible workaround or plan to support the same?

This can be especially useful since plugins should not be able to maliciously deprive the other containers of the pod from being able to use cpu resources.

[sleshchenko]

Currently, it's not allowed and AFAIK there are no plans to implement it soon.
@ibuziuk @amisevsk Maybe you have another input.

But it should not be very difficult, If you're interested to make a contribution to Che and you need some assistance I can help you.

[l0rd]

Please when start working on this issue take into consideration that we should add CPU limits, CPU request and memory request for che plugins and editors.

[amisevsk]

It's not implemented currently but I agree with @sleshchenko that it wouldn't be terribly difficult (apart from adding those fields where necessary). My only concern would be that it may be possible to shoot yourself in the foot since memory and cpu limit can interact (e.g. two workspace pods requesting 2Gi memory and 10000m CPU won't be able to be provisioned on a node due to CPU availability), and without a good way of getting metrics for plugins (it's very hard to set a default memory limit except through trial and error) it could make setting up a workspace significantly more complicated.

One reason it's not implemented is that for e.g. Hosted Che, an admission controller automatically assigns CPU limits based off memory limit. While perhaps not ideal, this avoids provisioning issues.

[l0rd]

@amisevsk that's not about making it mandatory to set the CPU limits but about having the possibility to do it.

You are right when you say that currently everything works fine on OSO. In the last 2 years we have designed the OpenShift infra so that it worked fine on OSO. But that's a peculiar OpenShift cluster and the admission controller you are mentioning (along with the storage backend etc...) is something that users won't find on different OpenShift/Kubernetes clusters.

Here is a common configuration of an OpenShift clusters:

• There is a default CPU limit per containers (for example 500mi)
• If the CPU limit for a container is not specified the default one is applied
• Namespaces have a CPU Quota per namespace (for example 2 cores)

In such a cluster, when a user starts a Che workspace with more than 4 containers (something pretty common: theia, machine-exec, 2 plugins and one runtime container) it fails miserably because the workspace pod exceeds the CPU quota! And there is nothing a user can do to fix that. There is no way to specify the CPU limit in the devfile and there is no way to specify it in the plugins meta.yaml neither. That's frustrating and pretty common on real world clusters.

That's an issue that has already been raised by customers, developers advocates, Red Hat SA and PMs preparing demos. You can easily reproduce it on RHDPS. This is currently a P1 but may become a blocker.

cc @slemeur @RickJWagner

[l0rd]

@mshaposhnik during priorisation yesterday I mentioned a scenario where I could reproduce the problem. That happened when I tried to load this devfile withing an RHDPS cluster.