Add workspace-like support for block devices

[bobcatfish]

Expected Behavior

With workspaces, users can declare files they need at Task authoring time, and users can satisfy those requirements at run time with PVCs, emptyDirs, etc.

They should similarly be able to declare when a Task requires a block device, and provide the volume that satisfies this at runtime.

Actual Behavior

If a user wants to use block devices, they have to fall back on using volumes + volumeDevices in Tasks (e.g. similar to this example tho that example is using volumeMounts not volumeDevices). This mixes runtime information in at Task authoring time (the Task is declaring the name and the type of the Volume).

Additional Info

More info about raw block volumes at https://kubernetes.io/blog/2019/03/07/raw-block-volume-support-to-beta/

Taking the example "Using a raw block PVC" from this page, the interface could look like this:

kind: Task
metadata:
  name: blocktask
spec:
  steps:
    - name: my-container
      image: busybox
      command:
        - sleep
        - “3600”
  devices:
  - name: mydevice
    description: some description
    devicePath: /dev/mydevice # unlike mountPath this would be required
---
apiVersion: tekton.dev/v1alpha1
kind: TaskRun
metadata:
  generateName: workspace-volume-
spec:
  taskRef:
    name: blocktask
  devices:
  - name: mydevice # provide the actual block device at runtime
     persistentVolumeClaim:
       claimName: my-pvc

@skaegi plz verify above ^^ :D

And speaking of @skaegi here is the version of this that he originally proposed: #1438 (comment)

[vdemeester]

/kind feature
/area api

[bobcatfish]

Discussed in beta working group, folks could continue to use podTemplates to accomplish this, even if we went ahead to remove Volumes in #2058, so this isn't a blocker for beta.

[bobcatfish]

... i did NOT mean to close this wow

[skaegi]

Hmm... after playing with the podTemplate technique one issue is that the definition is in the "taskrun" but the mounting is in the "task". Still a possible workaround but we really should add this support shortly.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[bobcatfish]

Interestingly we haven't had any further requests for this since opening the issue, so maybe closing it makes sense until someone really needs it.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[skaegi]

If I can get our local provisioner to work as a block storage provider this might become relevant again. I do have use-cases that need block storage but the availability of a "cheap" provisioner is holding this back.

[skaegi]

I have a concrete use-case for this now. We use a ClusterTask to do image builds that "needs" to run with Block storage. I am doing this behind the scenes with volume and volumeDevices but would like to at least look at modelling in the Task definition as a workspace variation.

[bobcatfish]

Thanks @skaegi !

/remove-lifecycle rotten

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.