Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow workspaces to disable/modify automatic project cloning #607

Closed
amisevsk opened this issue Sep 22, 2021 · 2 comments · Fixed by #673
Closed

Allow workspaces to disable/modify automatic project cloning #607

amisevsk opened this issue Sep 22, 2021 · 2 comments · Fixed by #673
Assignees
Labels
sprint/current Is assigned to issues which are planned to work on in the current team sprint

Comments

@amisevsk
Copy link
Collaborator

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

  1. 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
  2. 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.

kind: DevWorkspaceTemplate
apiVersion: workspace.devfile.io/v1alpha2
metadata:
  name: project-clone
spec:
  components:
  - name: project-clone
    container:
      image: quay.io/devfile/project-clone:next
      mountSources: true
      memoryLimit: "1Gi"
      memoryRequest: "128Mi"
      cpuLimit: "1000m"
      cpuRequest: "100m"
  commands:
  - id: clone-projects
    apply:
      component: project-clone
  events:
    prestart:
      - clone-projects
@benoitf
Copy link
Collaborator

benoitf commented Sep 22, 2021

Dup of #606 but you can close mine

@sleshchenko
Copy link
Member

+1 for option №1 from my end.

@sleshchenko sleshchenko self-assigned this Oct 12, 2021
@sleshchenko sleshchenko added sprint/current Is assigned to issues which are planned to work on in the current team sprint and removed sprint/next labels Oct 28, 2021
@amisevsk amisevsk assigned amisevsk and unassigned sleshchenko Nov 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
sprint/current Is assigned to issues which are planned to work on in the current team sprint
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants