Volume bound to a namespace and not a workspace

[benoitf]

Description

I would like to be able to get a volume that is bound to my user and not my workspace.
I would like to find my 'user files' in all workspaces

Additional context

For example, pre-populate some volumes when creating the user namespace so data are already there when I need it inside a workspace

I may have 'read-only' mode or 'read-write' mode on those depending on the usecase

[amisevsk]

Formal support for this could be provided via devfile/api#374 on the devfile/api side. As for the DevWorkspace Operator, we currently support auto-mounting existing volumes into all DevWorkspaces in a namespace via the automount labels:

• Label controller.devfile.io/mount-to-devworkspace defines a PVC as "should be mounted to DevWorkspaces"
• Annotation controller.devfile.io/mount-path defines the mount path within all containers where the PVC should be mounted
• Annotation controller.devfile.io/read-only defines if the PVC should be mounted read-only or not

[amisevsk]

The issue for documenting the annotations above is progressing: #577

[benoitf]

@amisevsk

so it seems it doesn't work if I want to use these attributes in the devfile.yaml (or a DevWorkspaceTemplate)

something like:

    components:
      - name: user-data
        volume: {}
        attributes:
           "controller.devfile.io/something-to-say-i-want-a-user-volume": "user-data"
           "controller.devfile.io/mount-path": "/user-data"

[amisevsk]

so it seems it doesn't work if I want to use these attributes in the devfile.yaml (or a DevWorkspaceTemplate)

That is correct. The reason behind this is that it blurs the line between workspace-scoped and namespace-scoped resources:

• Does DevWorkspace startup fail if the volume referenced in the attribute is not present?
  • If yes, this makes Devfiles not portable, as they assume out-of-lifecycle resources exist on the cluster -- this is the reason Support externally-defined volume components api#374 has been on hold.
• Is the DevWorkspace Operator responsible for creating/cleaning up the PVC?
  • How do we do that (i.e. when do we delete the user-data volume)? Workspace-specific storage is cleaned up on workspace removal, but there's no clear hook for deleting data outside of this context.
  • How does creating a user-data volume interact with storage classes (e.g. asynchronous, ephemeral)
  • If we delete the common PVC when all DevWorkspaces in a namespace are removed, does this mean deleting all your workspaces also erases any user-data you might have?

The DevWorkspace Operator is not aware of users in any way, so tracking additional storage is basically limited to DevWorkspaces in a Namespace. The idea is that someone/something that is aware of users can create an appropriate volume for user-data and manage it as required. The annotations on the volume itself enable that data to be added to any DevWorkspace in the namespace without worrying about conflicts (e.g. ephemeral or async storage workspaces, where the deployment gets only emptyDir volumes).

[sleshchenko]

Changed the title have namespace instead of use, since DWO technically knows a little about user.
It has userid but knows nothing about user lifecycle, which means leaving the leftovers on the cluster.
But anyway multiple users are not supposed to run their devworkspace in the same namespace, so namespace makes more sense.

[amisevsk]

Closing PR since this is not something we can support further than the current mechanism. Documentation for the existing feature is tracked in #657