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

Support externally-defined volume components #374

Closed
amisevsk opened this issue Mar 16, 2021 · 1 comment
Closed

Support externally-defined volume components #374

amisevsk opened this issue Mar 16, 2021 · 1 comment
Labels
area/api Enhancement or issue related to the api/devfile specification area/devworkspace Improvent or additions to the DevWorkspaces CRD kind/enhancement New feature or request lifecycle/rotten Rotten items. These items have been stale for 60 days and are now closed. lifecycle/stale Stale items. These items have not been updated for 90 days.

Comments

@amisevsk
Copy link
Contributor

Is your feature request related to a problem? Please describe.

This issue is a follow-up to the second half of #310 -- supporting "external" volumes.

We've seen use cases where users have defined volumes on their cluster (configmaps/secrets or persistent storage) that they would like to use with their devfiles -- for example:

  • Mounting an shared ROX volume containing assets to workspaces
  • Mounting secrets that are managed outside the scope of devfiles/the DevWorkspace operator

Implementation options

There are various ways to go about this, all with drawbacks

  1. Automatically mount configmaps/secrets/volumes based off of annotations on the underlying object (similar functionality is planned for DWO for secrets/configmaps). The downside is that the underlying objects have to be configured to support this, and it might be hard to follow for users.
  2. Add fields to volume components to support referencing cluster resources:
    spec:
      - name: my-external-volume
        volume:
          external: # Setting fields indicates that this is an external volume
            type: storage
            name: my-pvc
              
      - name: my-existing-secret
        volume:
          external:
            type: secret # or configmap
            name: my-secret
    the downside here is that such devfiles would only work on a cluster that has the external resources (i.e. they aren't widely portable). A user/organization using this functionality may not be too concerned, though.
  3. Same as 2. but introduce a new component type (externalVolume?) to make the distinction between the two clearer and avoid ambiguity around other volume component fields.

Additional context

Copy link

This issue is stale because it has been open for 90 days with no activity. Remove stale label or comment or this will be closed in 60 days.

@github-actions github-actions bot added the lifecycle/stale Stale items. These items have not been updated for 90 days. label Jul 20, 2024
@github-actions github-actions bot added the lifecycle/rotten Rotten items. These items have been stale for 60 days and are now closed. label Sep 18, 2024
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Sep 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/api Enhancement or issue related to the api/devfile specification area/devworkspace Improvent or additions to the DevWorkspaces CRD kind/enhancement New feature or request lifecycle/rotten Rotten items. These items have been stale for 60 days and are now closed. lifecycle/stale Stale items. These items have not been updated for 90 days.
Projects
None yet
Development

No branches or pull requests

1 participant