You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The DevWorkspace Operator automatically adds an init container to ensure projects are cloned before starting workspaces. However, since init containers in Kubernetes run sequentially, it may be possible to improve DevWorkspace startup time by allowing the init container to do multiple things in parallel (e.g. download .vsix extensions for Theia/VSCode).
DWO should have a mechanism to allow devworkspaces to override/disable the default behavior as necessary. There are generally two ways we could do this
Add DevWorkspace attribute to disable automatically injecting project clone container into a DevWorkspace
Pros: simple, easy to implement, and easy to understand (if you add this attribute, you are responsible for cloning projects)
Cons: more work for users, as recreating functionality (clone before start) requires adding their own init container
Add DevWorkspace attribute to allow devworkspaces to override the image used for project clone
Pros: potentially simpler to use, as you could potentially just extend the current project-clone image with additional functionality
Cons: ties the implementation of project clone container to any use case users might want to use an init container for
Personally, I think option 1 is better, since option 2 risks opening project clone functionality into a larger "use this image as an init container" feature. This could mean that making changes to project-clone breaks devfiles in ways we can't test, and couples DevWorkspace instances with the DevWorkspace Operator in a way I'd like to avoid. A particular concern is that we set the memory/cpu limit for project clone based on our known use-case, and it would be hard to accomodate additional functionality in a stable way.
Additional info
The net effect of adding the project clone container on a DevWorkspace is importing the DevWorkspaceTemplate below, so it should be fairly simple to re-implement custom project cloning as a plugin.
Description
The DevWorkspace Operator automatically adds an init container to ensure projects are cloned before starting workspaces. However, since init containers in Kubernetes run sequentially, it may be possible to improve DevWorkspace startup time by allowing the init container to do multiple things in parallel (e.g. download .vsix extensions for Theia/VSCode).
DWO should have a mechanism to allow devworkspaces to override/disable the default behavior as necessary. There are generally two ways we could do this
Personally, I think option 1 is better, since option 2 risks opening project clone functionality into a larger "use this image as an init container" feature. This could mean that making changes to project-clone breaks devfiles in ways we can't test, and couples DevWorkspace instances with the DevWorkspace Operator in a way I'd like to avoid. A particular concern is that we set the memory/cpu limit for project clone based on our known use-case, and it would be hard to accomodate additional functionality in a stable way.
Additional info
The net effect of adding the project clone container on a DevWorkspace is importing the DevWorkspaceTemplate below, so it should be fairly simple to re-implement custom project cloning as a plugin.
The text was updated successfully, but these errors were encountered: