Ability to bind Workspaces

[davissp14]

It would be really nice to be able to configure a workspace prior to creating a PipelineRun within the dashboard.

I understand that triggers can be used to do this automatically through events, but for folks who want to manually kick something off through the dashboard, this would be pretty useful.

[AlanGreene]

I agree it would be nice to be able to manually create runs using workspaces.

We're currently working on introducing the ability to manually create a TaskRun, similar to the existing functionality for PipelineRuns. As part of this we're likely to revisit some of the PipelineRun pieces.

Some initial thoughts for anyone interested in picking this up...

Adding support for workspaces would require:

• knowledge of available PVCs, ConfigMaps, changes to how we handle Secrets
  • would it be sufficient to list existing resources of these types without providing the ability to create / edit them?
• similar logic as we have for resources / params to detect the required workspaces and present them in the create UI
  • given the potential for many more items in this UI we really should look at moving to the full page experience instead of the current modal dialog, see item 5 of Misc. Front End Development Specs for Dashboard Designs #966
• possibly more...

Reference:

• Workspaces docs. More info in TaskRun and PipelineRun docs that may be of use.
• TaskRun example
• PipelineRun example

[davissp14]

It seems a little silly that workspace definitions happen on the PipelineRun/TaskRun resource given how they are used. Basically, you'd have to specify one-to-many workspaces, per run, and hope that the end-user is able to map the bindings correctly when a new run is issued. It's not a very good experience. It also doesn't look like there's a reliable way to determine the workspace specifications/requirements by simply reading the pipeline/task definitions, which makes it even harder.

Seems like there needs to be another level of abstraction that holds the configuration/binding definitions so they can be re-used across runs.

[AlanGreene]

Depending on your specific use cases, if you're looking for a way to template the creation of runs you may be interested in Tekton Triggers.

Triggers enables users to map fields from an event payload into resource
templates. Put another way, this allows events to both model and instantiate
themselves as Kubernetes resources. In the case of tektoncd/pipeline, this
makes it easy to encapsulate configuration into PipelineRuns and
PipelineResources.

Changes to how Pipelines / Tasks are defined would need to raised against the core Tekton Pipelines and likely raised for discussion at the weekly working group meeting. Since Pipelines and Tasks are intended to be reusable, configuration such as workspaces, service accounts, resources, etc. are considered runtime options. See tektoncd/pipeline#2141 and tektoncd/pipeline#2140 (comment).

[davissp14]

I actually opened up a related issue shortly after I opened up this one. Thank you!

[davissp14]

Here's a link to the related issue: tektoncd/pipeline#2372

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

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.

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

[AlanGreene]

/remove-lifecycle stale
/remove-lifecycle rotten
/reopen

[tekton-robot]

@AlanGreene: Reopened this issue.

In response to this:

/remove-lifecycle stale
/remove-lifecycle rotten
/reopen

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.

[AlanGreene]

/assign @ziheng

[tekton-robot]

@AlanGreene: GitHub didn't allow me to assign the following users: ziheng.

Note that only tektoncd members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign @ziheng

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.

[AlanGreene]

Moving the Create TaskRun UI to a full-page experience as we've already done for Create PipelineResource and Create Secret should be happening very soon: #966

Once this is done we'll have more space to work with and may make some further layout changes to the existing Create PipelineRun / TaskRun UI. These would allow us to provide a cleaner and more user friendly experience, especially as we start adding more functionality, e.g. #1722

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

[AlanGreene]

This is still something we want to add, freezing so it doesn't get automatically closed.

/lifecycle frozen

[morningspace]

Any update for this issue? Really looking forward to this feature. Without specifying workspace, it looks the manually kicking off PipelineRun or TaskRun feature is not really useful in many cases.

[jasperjonker]

I am also curious, would be extremely helpful to trigger pipelines from the dashboard

[marniks7]

Hi,

• List of sources to support: PVC, ConfigMap, Secrets, emptyDir, VolumeClaimTemplate, projected (alpha), csi (alpha).
• Features: subPath for PVC,
  What the use cases for subPath we have? not sure how users should understand what to put there

Basic Solution

PVC, ConfigMap, Secrets, emptyDir only

• Basic solution is to show dropdown with names of configMaps, Secrets and PVC
  

• Also, it is possible to add types before names, like secret: default-token-6q424, configmap: kube-root-ca.crt

• I am surprised to see router.go as api proxy for kubernetes API(s) allowing to list everything with related clusterrole access. In order to work with secrets, api should expose only required endpoints without providing access to secrets itself. Unfortunately, there is no RBAC access in k8s to read only secret metadata. (list access will allow to read everything). As of now idk how to solve this problem on security level... admins will need to give list access for secrets to tekton-dashboard-backend.

subPath

• subPath (but should be displayed only for PVC) :
  

More complex

VolumeClaimTemplate, projected (alpha), csi (alpha) not analyzed

[AlanGreene]

I am surprised to see router.go as api proxy for kubernetes API(s) allowing to list everything with related clusterrole access. In order to work with secrets, api should expose only required endpoints without providing access to secrets itself.

Yes we would need to either apply a filter to the Secret endpoints to return only the basic metadata, provide a custom endpoint specifically for this purpose (and block the default endpoint), or provide free-text input for the Secret name in the UI instead of providing a dropdown list from which the user would select.

[dgsfor]

Hi,

• List of sources to support: PVC, ConfigMap, Secrets, emptyDir, VolumeClaimTemplate, projected (alpha), csi (alpha).
• Features: subPath for PVC,
  What the use cases for subPath we have? not sure how users should understand what to put there

Basic Solution

PVC, ConfigMap, Secrets, emptyDir only

• Basic solution is to show dropdown with names of configMaps, Secrets and PVC
  
• Also, it is possible to add types before names, like secret: default-token-6q424, configmap: kube-root-ca.crt
• I am surprised to see router.go as api proxy for kubernetes API(s) allowing to list everything with related clusterrole access. In order to work with secrets, api should expose only required endpoints without providing access to secrets itself. Unfortunately, there is no RBAC access in k8s to read only secret metadata. (list access will allow to read everything). As of now idk how to solve this problem on security level... admins will need to give list access for secrets to tekton-dashboard-backend.

subPath

• subPath (but should be displayed only for PVC) :
  

More complex

VolumeClaimTemplate, projected (alpha), csi (alpha) not analyzed

In my pipeline, different tasks use different workspaces and serviceaccounts, so hopefully UI will be able to support it as well.
like this:

      apiVersion: tekton.dev/v1beta1
      kind: PipelineRun
      metadata:
        generateName: my-pipelinerun-
        namespace: tekton-run
      spec:
        taskRunSpecs:
          - pipelineTaskName: fetch-ops-git
            taskServiceAccountName: sa-gitlab-clone
          - pipelineTaskName: fetch-app-git
            taskServiceAccountName: sa-gitlab-clone
          - pipelineTaskName: azure-git-action
            taskServiceAccountName: sa-azure-git-action
        pipelineRef:
          name: php-pipeline-pre
        workspaces:
          - name: git-clone-workspace
            persistentVolumeClaim:
              claimName: pvc-tekton
            subPath: pvc-$(uid)
          - name: image-secret-workspace
            secret:
              secretName: swr-image-secret
          - name: azure-git-action-workspace
            emptyDir: {}

[marniks7]

With new YAML mode any user-specific cases are supported now, and we may continue discussion.

@AlanGreene, I agree that secrets should not be allowed to read by dashboard UI for those who are concerned with security and we can support both options:

1. Provide ability to specify secret name without dropdown (less user friendly, since user will need to know somehow the name, but better for those concerned about security)
2. In case if access to secrets provided for specific namespace and specific user - show dropdown

[AlanGreene]

/area roadmap

[dgsfor]

Been looking forward to this feature for a long time

[dgsfor]

Been looking forward to this feature for a long time

YAML mode, no problem for SRE, but compared to ordinary R&D personnel, the threshold is a bit high, they just want to perform simple operations through the dashboard. @AlanGreene

[ileixe]

+1 from user perspective. This would be an import issue to use dashboard as frontend workflow while the workspace is the very first primitive for pipeline.