Workspace, configmap, secret and typing

[vdemeester]

As a user, and an integrator of Tekton, I find something a bit unsettling with the way we made Workspace work.

Workspaces allow Tasks to declare parts of the filesystem that need to be provided
at runtime by TaskRuns. A TaskRun can make these parts of the filesystem available
in many ways: using a read-only ConfigMap or Secret, an existing PersistentVolumeClaim
shared with other Tasks, create a PersistentVolumeClaim from a provided VolumeClaimTemplate, or simply an emptyDir that is discarded when the TaskRun
completes.

Workspaces are similar to Volumes except that they allow a Task author
to defer to users and their TaskRuns when deciding which class of storage to use.

Workspaces can serve the following purposes:

• Storage of inputs and/or outputs
• Sharing data among Tasks
• A mount point for credentials held in Secrets
• A mount point for configurations held in ConfigMaps
• A mount point for common tools shared by an organization
• A cache of build artifacts that speed up jobs

We are using Workspace for two type of operation: sharing data between task and providing something required by the task (config, secret, cache, …) that is not readable.

When writing a Task, there is no way to convey which type of workspace is what. Let's assume I am taking 4 workspaces, one for sharing data (the source), one to get some credential (the secret), one optional to get some tooling configuration (the configmap) and another optional to provide some cache (the cache). Except from reading the name, there is no way to know that the first Workspace should be writable and the rest should not, or that the first or last ones might or might not need to be provisionned (aka could be empty) but the 2 others (secret and configmap) should contain something, and something specific even.

This is getting even more trickier when integrating Tekton, if, for example, we want to provide our user a way to not have to care too much about the sharing data workspace and have some sane defaults around here. As of today, there is no way, from a Pipeline or a Task definition, to know that this (or these) workspace(s) should be writable and those should not. Thus it makes it really hard to provide a default Workspace to our users.

I don't have especially strong thoughts around how to fix that, but here is a few ideas:

• Make Workspace solely for sharing data, and make the secret/configmap handling more explicit in Tekton (aka having a field or set of fields dedicated to them) — question is open if we could use volumes for handling them (see Towards v1 API #3548 (comment)).
• Add some sort of typing on the Workspace aka be able to say "this is for sharing data, this is for configuration or secrets", … It would ties it to any type of volume behind the scene (letting this up to the user still), but it would help tools interact a bit more.
• Add a way to attach "meaning" to a Workspace in definitions, a bit like metadatas (labels ?). Idea here would be that, by convention, we could "label" a workspace as main (the main sharing data workspace), on with cache or `credentials", …

/kind feature
/kind discussions

[vdemeester]

/cc @sbwsg
/cc @tektoncd/core-maintainers

[ghost]

I've received some requests to allow a workspace declaration to specify a minimum required size for the volume.

Also digest info for specific file paths on a workspace.

I'm generally in favor of something to let users shape their workspaces better. Would also definitely like to make it Volume-agnostic so that we're not embedding more k8s-specific stuff than what's already in WorkspaceBinding.

Tags or validation helpers of some kind? Here's a hand-wavey bit of YAML:

kind: Task
spec:
  workspaces:
  - name: source
    requirements:
    - storage: persistent # tell tekton the volume must retain data across tasks. other options: "ephemeral"
    - minSize: 256M
    - writeable: true # this task plans to put content on the volume
    - digests:
        /path/to/foo: abcdef123 # entrypoint can check these?
        /path/to/bar: ghijkl456

In regards the "meaning", something like:

kind: Task
spec:
  workspaces:
  - name: input-workspace
    profile: source-code # or "configuration", "credentials", "test-results", "output-artifacts"

Or maybe the profile is a hint to Tekton for it to look up some configuration in a ConfigMap and auto-inject some volume or something?

Edit after API WG: Vincent mentioned that the problem feels like it's maybe more with Pipelines than Tasks.

[ghost]

• sharing data
• credential
• tooling configuration
• cache

This looks like a reasonable set of classifications to start with. How might they be used by a Pipeline author? And how could an integrator leverage this type information?

kind: Pipeline
spec:
  workspaces:
  - name: source
    type: shared-data
  - name: dependency-cache
    type: cache
  - name: build-artifacts
    type: shared-data  # Maybe we want a specific output-artifacts type?
  - name: ssh-credentials
    type: credential
  - name: lint-settings
    type: config

[vdemeester]

How might they be used by a Pipeline author? And how could an integrator leverage this type information?

That's up to them, but it would give some hints to the integrator on what to "hook" to these workspaces (using some labels or whatever, it's out of pipeline's reach).

[ghost]

Hm, I meant more like, "If someone writes a TEP for this, what do we put in the Use Cases section?" At the moment I don't think we have any actual concrete use cases.

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

[vdemeester]

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

[jerop]

/lifecycle frozen