[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: amisevsk

The full list of commands accepted by this bot can be found here.

The pull request process is described here

You starts watching all LimitRange objects which can affect DWO memory usage.

Yeah this is the tradeoff (and partly why I don't think considering limitranges is a good approach in general).

Either we cache all limitranges (which could potentially take a lot of memory) or make API requests on every reconcile (which leads to a variety of problems).

With caching, we can expect an increase in memory usage on the order of ~200 MB depending on cluster size (small clusters shouldn't really have a problem)

Without caching, we have to worry about DWO making a lot of requests against the API in unpredicable patterns, and also tie the reconcile loop to API latency, which could cause instability in starting workspaces.

IMO it's sufficient that the project-clone container can be configured to not have a CPU limit, and we shouldn't be looking at limitranges at all. We should do the safe, compatible thing in default DWO containers (set a CPU limit that is sufficient for the performance we expect) and allow a way to remove the CPU limit when desired.

cc: @l0rd any thoughts here?

I agree with you. Watching the LimitRanges is overkill and may have some major side effects.

That's my proposal: when the operator is deployed, based on the information that we have, we should decide (in advance) if we can avoid setting the CPU limits for workspaces UDI, project-clone and gateway containers. But how can we decide that when the developer namespaces don't exist yet? Well my guess would be that, if the CheCluster namespace has a default container CPU limit, then developers namespaces will have it too. Of course this is an extremely weak assumption so maybe it's better to do what @amisevsk proposes. But not setting the CPU limits is so better, it provides such a better UX, that I feel bad that we set it by default on the workspaces containers. Of course admins should have a way to enforce a different default behavior (that can be setting a specific CPU limit or not setting it at all).

Out of curiosity: do you know if Developer Sandbox has a default CPU limit in the openshift-devspaces namespace?

Out of curiosity: do you know if Developer Sandbox has a default CPU limit in the openshift-devspaces namespace?

I just double-checked, and sadly the sandbox clusters don't have limitranges in non-user namespaces, so this heuristic wouldn't work there.

Currently, the places CPU limits are used in DWO are

• The Operator's controller/webhooks containers have CPU limits set -- I'd love to be able to remove these to see if it improves workspace startup time, but they're defined in the CSV itself so it's likely a no-go.
• The project-clone container uses a default CPU limit to be safe, but this can be disabled via the DevWorkspaceOperatorConfig CR (and this field is supported by Eclipse Che as of the last release). I'm not sure how much of an impact the CPU limit has here, as this container may be bound by network rather than CPU (we should test this).

In particular, we don't set CPU limits on workspace containers by default, so if a DevWorkspace is created that e.g. doesn't set a limit on the tools container, that container will be run without a limit (the same applies for CPU requests, actually).

Related to this issue I think is the issue @AObuchow is working on: #1056. Currently, if we merge a contribution (e.g. the editor) into the default development container, we get a CPU limit from that container that we don't necessarily want. Once #1056 is resolved, we should be able to run any non-project-clone containers without a CPU limit by just not setting a CPU limit in devfiles.

Closing this pull request as I don't think it's something we want to do in DWO; CPU limits can now be configured for every container so it's possible to remove them as required.