search

eclipse-che / che

Kubernetes based Cloud Development Environments for Enterprise Teams
http://eclipse.org/che
Eclipse Public License 2.0
6.96k stars 1.19k forks source link

Extensions running in the main Theia container should update memory limit for Theia #14511

Open amisevsk opened 5 years ago

amisevsk commented 5 years ago

Is your enhancement related to a problem? Please describe.

While most extensions we currently support have additional dependencies and thus have to run in a sidecar, some extensions run fine in the main Theia container. For these extensions, it would be better to not provision an additional sidecar with memory limit if possible.

This however, could run into an issue where installing plugins into the main Theia container causes memory issues. If a particularly memory-hungry plugin is added, it could cause the container to be killed, crashing the workspace.

Describe the solution you'd like

  1. Revise the plugin meta.yaml schema to support specifying a memory requirement for extensions that do not run in a sidecar

  2. When starting a workspace, add the specified memory requirement for all sidecar plugins to the memory limit given for the main Theia container. For example, if my workspace has

    • Theia, with a default memory limit of 512M
    • vscode-yaml, with a memory request of 256Mi (note, the vscode-yaml extension in this example would not have a containers field, and specify its memory requirement in another way)

    the workspace should be started with a default memory limit of 512 + 256 = 768Mi to prevent memory issues.

Describe alternatives you've considered

Doing nothing also works, but could result in a case where adding a plugin to the workspace causes the Theia container to crash. This would have to be resolved by manually increasing the memory allocated to the main Theia container. This could also be managed by specifying a generous default for Theia to accommodate a few local plugins.

Additional context

https://github.com/eclipse/che/issues/13555

slemeur commented 5 years ago

This is a nice ux improvement IMO. We should also take care of this when the user wants to install a plug-in in an already running workspace (from the IDE - plugin panel).

che-bot commented 4 years ago

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.

amisevsk commented 4 years ago

/remove-lifecycle stale

amisevsk commented 4 years ago

cc: @davidfestal @l0rd seems that this could be something taken into account with a new devfile spec

l0rd commented 4 years ago

@amisevsk we definitely need to address this issue. I am not sure how we could address that in the new spec though. I would rather consider it an implementation issue.

amisevsk commented 4 years ago

@l0rd the spec-specific fix I was thinking about was that non-sidecar containers currently cannot specify their memory/cpu requirements, so in the example we wouldn't know how much to increase the main Theia container's limit.

l0rd commented 4 years ago

Ok I see. We currently specify mem/cpu requirements at the container level. For a plugin with no containers we cannot specify the mem/cpu requirements.

che-bot commented 3 years ago

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.