eclipse-che
Allow for global configuration of workspace resource requests
Is your enhancement related to a problem? Please describe
An inexperienced developer can cause a cluster node to become unschedulable by creating a devfile which has extreme values for cpuRequest or memoryRequest
Describe the solution you'd like
- Allow for global configuration of the default
cpuRequest&memoryRequestvalues. - Allow for global configuration to ignore devfile defined
cpuRequest&memoryRequestentries in a devfiles. - If
cpuLimitormemoryLimitis set in a devfile, thecpuRequest&memoryRequestshould still use the default values and not be set to the requested limits.
Describe alternatives you've considered
No response
Additional context
No response
@cgruver in the recent release we introduced a new feature allowing configuring user namespaces with an OpenShift template which I believe should address this issue - https://github.com/eclipse-che/che/releases/tag/7.94.0
@ibuziuk Let me take a look at that.
I would still like to consider configurable defaults.
Plus, it feels like an anti-pattern that we set limit and requests to be the same if only one of them is specified.
I may open that as a separate issue. IMO, it's a bug that I can override a default by setting a different parameter.
I would still like to consider configurable defaults.
Well, it is configurable as soon as limit ranges are applied on the namespace level, right? The analogy would be the default flat pod network which is configurable on the cluster by applying specific network policies.
Plus, it feels like an anti-pattern that we set limit and requests to be the same if only one of them is specified.
Well, this is a nuanced approach - CDE is guaranteed the requested resources, preventing performance degradation for more or less stable workloads
Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.
Mark the issue as fresh with /remove-lifecycle stale in a new comment.
If this issue is safe to close now please do so.
Moderators: Add lifecycle/frozen label to avoid stale mode.
With the merge of https://github.com/devfile/devworkspace-operator/pull/1545, the DevWorkspace operator introduced new field, containerResourceCaps:
kind: DevWorkspaceOperatorConfig
metadata:
name: devworkspace-operator-config
namespace: openshift-operators
apiVersion: controller.devfile.io/v1alpha1
config:
workspace:
containerResourceCaps:
limits:
cpu: "1"
memory: 2Gi
requests:
cpu: "0.1"
memory: 100Mi
Which sets the maximum limit and requests for cpu and memory. The fields can also be configured in the CheCluster: https://github.com/eclipse-che/che-operator/pull/2069
If the requests and limits in the devfile exceed these maximums set in the DWOC/CheCluster, the maximums will be used instead.
Going through the initial requirements:
- Allow for global configuration of the default cpuRequest & memoryRequest values.
This is set using the spec.devEnvironments.defaultContainerResources field in the CheCluster. The fields will be used when no limits/requests are specified in the devfile.
- Allow for global configuration to ignore devfile defined cpuRequest & memoryRequest entries in a devfiles.
- If cpuLimit or memoryLimit is set in a devfile, the cpuRequest & memoryRequest should still use the default values and not be set to the requested limits.
The new spec.devEnvironments.containerResourceCaps field acts a similar way. Basically, the containerResourceCaps are applied only if the devfile limits/request exceed the containerResourceCaps. If what's defined in the devfile is less than the cap, the devfile-defined limits/requests are not ignored, but will be used instead.
At the moment, there isn't a way to ignore all limits/requests defined in the devfile, and replace them with a global configuration (ex, defaultContainerResources). @cgruver is this something you still need, or does containerResourceCaps satisfy your use case?