Relax TriggerTemplate limitation of only creating Tekton resources

[disposab1e]

Expected Behavior

It should be possible to create a PersistentVolumeClaim resource in TriggerTemplate spec.resourcetemplates:.

Actual Behavior

Only Tekton resources are allowed.

Steps to Reproduce the Problem

We would like to have a possibilty to dynamically create a PVC within TriggerTemplate.

apiVersion: tekton.dev/v1alpha1
kind: TriggerTemplate
metadata:
 name: pipeline-tt
 namespace: awesome-pipelines
spec:
 params:
 - name: pipelineName
   description: Pipeline Name (build, deploy, verify)    
resourcetemplates:
- apiVersion: v1
  kind: PersistentVolumeClaim
  metadata:
    name: $(uid)
  spec:
    resources:
      requests:
        storage: 0.2Gi
    accessModes:
      - ReadWriteMany
 - apiVersion: tekton.dev/v1alpha1
   kind: PipelineRun
   metadata:
     generateName: pipeline-run-
   spec:
     serviceAccountName: pipeline-sa
     pipelineRef:
       name: pipeline-$(params.pipelineName)
     workspaces:
     - name: pipeline-workspace
       persistentVolumeClaim:
         claimName: `$(uid)`

We don't think this will break any design decisions but can be very helpful in some dynamic scenarios.

In this context we really miss "support" for workspace lifecycle management. For example cleaning up a workspace (and optional PVC) after:

• Success
• Error (support from Error Handling and Allowing for actions to be taken in failure scenarios)
• Hooks (support from Lifecycle Management)
• House keeping House keeper for Pipeline related stuff #64

We also follow the Auto Workspaces discussion.

Additional Info

This issue has its roots here.

[ncskier]

/kind feature

[bitsofinfo]

@disposab1e do you currently have any workaround/hack way you create these PVCs dynamically before a PipelineRun invokes? care to share?

[vtereso]

Due to security considerations, we want to make sure we do this right and that the use case is warranted. Auto workspaces might be able to support your use case. We will continue to look at this.

[disposab1e]

@vtereso What are your security concerns? Where is a auto workspace feature?

[vdemeester]

@disposab1e auto workspace is there : tektoncd/pipeline#1986
@vtereso can you elaborate on the security concern ? what differs from creating tekton resources and pvcs ? (if the user has the rights to do so)

[disposab1e]

@vdemeester Perhaps it will be there? Still open, nothing to use right now.

[vdemeester]

@vdemeester Perhaps it will be there? Still open, nothing to use right now.

On auto-workspace, yeah, there is no auto-workspace yet, which makes using workspace with dynamically provisionned PVC close to impossible with triggers indeed 😓

[disposab1e]

I do not agree! I can use workspace feature with dynamically provisioned PVCs. Ok it's harder without error handling and without lifecycle management. Still two features I'm really mssing in a professionell environment.

[vdemeester]

I do not agree! I can use workspace feature with dynamically provisioned PVCs. Ok it's harder without error handling and without lifecycle management. Still two features I'm really mssing in a professionell environment.

My comment above says that it's hard as of today (not being able to create PersistentVolumeClaim in a TriggerTemplate), which I think is a problem (hence my question to @vtereso). I didn't mean that it shouldn't be supported, but the opposite, I think it should be supported (otherwise this mean we need to do an extra hoop to create dynamic PVC, like have a Task that creates it and then triggers something else…)

[disposab1e]

I think there must be "something" when you remove PipelineResources in the future. I totally understand the discussions about not to pin tekton-pipelines to a specific way to store data between tasks. But it's a common use case "the need for storage". I had this discussion in mind when I was asking for PVCs in TriggerTemplates. I don't think this will break your design decissions. But when you create something, you also have to remove something. That's why error handling and/or lifecycle management will be very important in the furture. And to be honest for me it's not understandable that these use cases are NOT part of any design so far.

[dibyom]

@vtereso can you elaborate on the security concern ? what differs from creating tekton resources and pvcs ? (if the user has the rights to do so)

I think the security issues are the same as mentioned in #77

[jlpettersson]

@disposab1e @vdemeester @vtereso I agree with you all! This is a blocker before using Tekton in a professional environment. I spent some time and submitted tektoncd/pipeline#2326 for the solution I proposed in the auto workspace issue.

[disposab1e]

@jlpettersson Looks wonderful! I like the idea that the PVC is deleted when TaskRun, PipelineRun is deleted!

[dibyom]

The use case mentioned in this issue is now possible using volumeClaimTemplate. I'm going to close this out now but we can re-open if any new use cases pop up that needs Triggers to create non-Tekton resources.

[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]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/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.
Mark the issue as fresh with /remove-lifecycle rotten.

/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.