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

per-workspace storage PVC size calculation is incorrect when no volumes defined & mountSources used #1239

Open
AObuchow opened this issue Mar 13, 2024 · 1 comment
Assignees
Labels
bug Something isn't working

Comments

@AObuchow
Copy link
Collaborator

Description

If a devworkspace uses per-workspace storage, has mountSources: true but has no volumes defined, the calculated PVC size will erroneously be 0.

How To Reproduce

  1. Apply the following devworkspace that has no volumes & uses per-workspace storage:
kind: DevWorkspace
apiVersion: workspace.devfile.io/v1alpha2
metadata:
  name: plain-per-workspace
spec:
  started: true
  routingClass: 'basic'
  template:
    attributes:
        controller.devfile.io/storage-type: per-workspace
    components:
      - name: web-terminal
        container:
          image: quay.io/wto/web-terminal-tooling:next
          memoryRequest: 256Mi
          memoryLimit: 512Mi
          mountSources: true
          command:
           - "tail"
           - "-f"
           - "/dev/null"
  1. The DevWorkspace will fail with the following error:
Error provisioning storage: Failed to sync storage-workspace8723f4cb2dfa4922 PVC to cluster: PersistentVolumeClaim "storage-workspace8723f4cb2dfa4922" is invalid: spec.resources[storage]: Invalid value: "0": must be greater than zero

Expected behavior

If a devworkspace which does not define any volumes but has mountSources enabled, then the default PVC size should be used when using the per-workspace storage strategy.

@AObuchow AObuchow added the bug Something isn't working label Mar 13, 2024
@AObuchow AObuchow self-assigned this Mar 13, 2024
@AObuchow AObuchow moved this to 📅 Planned for this Sprint in Eclipse Che Team B Backlog Mar 13, 2024
@AObuchow AObuchow moved this from 📅 Planned for this Sprint to 🚧 In Progress in Eclipse Che Team B Backlog Apr 8, 2024
AObuchow added a commit to AObuchow/devworkspace-operator that referenced this issue Apr 17, 2024
Fix devfile#1239

This commit fixes an edge case where a devworkspace that has no volume components,
but has a container component with mountSources enabled will request a PVC size of 0
when using the per-workspace storage strategy.

When mountSources are used, the devworkspace requires storage to store the project sources.
However, it is unknown how much storage is actually required for the project sources.
Thus, we treat container components with mountSources enabled as if they were volume components
with an unspecified size.

Signed-off-by: Andrew Obuchowicz <[email protected]>
@AObuchow AObuchow changed the title per-workspace storage PVC size calculation is incorrect when no volumes defined per-workspace storage PVC size calculation is incorrect when no volumes defined & mountSources used Apr 17, 2024
AObuchow added a commit to AObuchow/devworkspace-operator that referenced this issue Apr 17, 2024
Fix devfile#1239

This commit fixes an edge case where a devworkspace that has no volume components,
but has a container component with mountSources enabled will request a PVC size of 0
when using the per-workspace storage strategy.

When mountSources are used, the devworkspace requires storage to store the project sources.
However, it is unknown how much storage is actually required for the project sources.
Thus, we treat container components with mountSources enabled as if they were volume components
with an unspecified size.

Signed-off-by: Andrew Obuchowicz <[email protected]>
@AObuchow AObuchow moved this from 🚧 In Progress to Ready for Review in Eclipse Che Team B Backlog Apr 17, 2024
@AObuchow AObuchow moved this to 📋 Backlog (not in current Sprint) in Eclipse Che Team B Backlog Sep 10, 2024
@AObuchow
Copy link
Collaborator Author

AObuchow commented Dec 6, 2024

The original PR aiming to resolve this issue has been closed as I didn't get a chance to continue my work on it (low priority), but the solution I wanted to use for this issue is described in this comment:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant