tkn pipeline start --workspace support for volumeClaimTemplates

[mnuttall]

Version and Operating System

tkn Version: 0.9.0

Operating System: Tekton Pipeline v0.12.1

Expected Behavior

volumeClaimTemplates in Pipelines v0.12.1 are a nice way to start PipelineRuns with a dynamically generated PersistentVolumeClaim (PVC). See here for a sample in the main code base. The tkn docs list several options when using tkn pipeline start to specify workspace settings, but they do not include support for volumeClaimTemplates.

Without this support, Tekton v1beta1 pipelines using workspaces and no PipelineResources are easier to start using kubectl create [PipelineResource] than tkn pipeline start, because volumeClaimTemplates are so extremely useful. They are however rather verbose:

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: run-with-template-
spec:
  pipelineRef:
    name: cat-pipeline-readme
  workspaces:
    - name: shared-workspace
      volumeClaimTemplate:
        metadata:
          name: mypvc
        spec:
          accessModes:
            - ReadWriteOnce
          resources:
            requests:
              storage: 50Mi

Almost all of this is boilerplate that could be auto-generated. If tkn wanted to pick a default storage size then we could

tkn pipeline start [name] --workspace name=[name],volumeClaimTemplate=true

If we did not want to go that far, maybe

tkn pipeline start [name] --workspace name=[ws],volumeClaimTemplate=name=myPrefix,size=50Mi

Flattening the volumeClaimTemplate into comma separated values in a usable way seems like the hardest part of the problem.

Actual Behavior

--workspace does not support volumeClaimTemplates as of tkn v0.9.

Steps to Reproduce the Problem

1. Attempt to turn this into tkn syntax
2. Notice it's not possible

Additional Info

[jlpettersson]

I could give this a try, haven't contributed to the cli yet.

I can try to implement:

tkn pipeline start [mypipline] --workspace name=[myws],volumeClaimTemplate=size=50Mi

[vdemeester]

/kind feature

[vdemeester]

/assign @jlpettersson

[danielhelfand]

/assign

[danielhelfand]

I wanted to open this up for further discussion on what volumeClaimTemplate properties would be valuable to support as a starting point for this issue? We can always add more later, but it might be better to start with some basic properties. Would the following be a good starting point?

• spec.resources.requests.storage
• spec.StorageClassName
• spec.AccessModes - Only support ReadWriteOnce initially

Supporting the entire volumeClaimTemplate as mentioned above will be difficult, so I think making sure we support common workflows with workspaces/volumeClaimTemplates to at least start is the best approach.

[vdemeester]

I think they are a good starting point. We can start with those and see if we need to support more when gather feedback from users 👼

[pradeepitm12]

Should we also create multiple/sub issues so others can also contribute, and having a smaller goal in the issue would make things easier.

[danielhelfand]

I am wondering if it makes sense to support something along the lines of the following UX:

tkn pipeline start [name] --workspace name=[name],volumeClaimTemplateFile=/path/to/volumeclaimtemplate.yaml

This would allow a user to define all properties of a volumeClaimTemplate in a file. We could even support a --volumeClaimTemplate flag at the TaskRun/PipelineRun level with tkn t start and tkn p start. I think my worry is that having an approach like tkn pipeline start [name] --workspace name=[ws],volumeClaimTemplate=name=myPrefix,size=50Mi will be too difficult to support over time.

We could maybe even allow support for a few properties with --workspace to be overrode via arguments to --workspace:

tkn pipeline start [name] --workspace name=[name],volumeClaimTemplateFile=/path/to/volumeclaimtemplate.yaml,storageRequest=50Mi

This could allow users specify certain properties regardless of what is defined in their file definitions while also supporting basic properties directly through tkn as originally proposed.