-
Notifications
You must be signed in to change notification settings - Fork 222
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TEP-0112] Replace volumes with Workspaces [Proposal] #720
Conversation
Addresses tektoncd/pipeline#2058 @vdemeester @skaegi PTAL |
/hold need to do a bit more digging--will revisit the proposal to support hostPath |
/hold cancel |
/assign @dibyom @pierretasci |
8fc72a1
to
40b3093
Compare
54e660c
to
007cabb
Compare
I chatted with @pierretasci yesterday about the "dynamic volumes" use case, and added it here as an existing use case that workspaces don't support. I need to think more about what we should do about this, but for now I added "dynamic workspaces" as an optional workspace enhancement. We are both in agreement that this is the right long-term direction for volumes/workspaces, but want to avoid removing support for an existing use case even if it isn't an "intended" use of the API. I've also added more detail on the options for different volume types we might want to support in workspaces, including embedding the k8s volumesource in workspacebinding. For now I think the existing workspace binding options are sufficient for the use cases we're targeting. |
The only Catalog Task using hostPath volumes is [`kind`](https://hub.tekton.dev/tekton/task/kind). | ||
For more information on why `kind` on Kubernetes requires hostPath volumes, see | ||
https://github.com/kubernetes-sigs/kind/issues/303#issuecomment-521384993 and | ||
[Running KIND Inside A Kubernetes Cluster For Continuous Integration](https://d2iq.com/blog/running-kind-inside-a-kubernetes-cluster-for-continuous-integration) | ||
(TL;DR: because `kind` needs to create nested Docker containers). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What would be the alternative here if we removed workspaces?
I agree that using volumes directly instead of workspaces is not a best practice, but unless we have an alternative here I wonder if we could address this by documentation, i.e. make sure that volumes are not used in any example / catalog task unless were strictly required. We could add a special page / section to document this feature as something we do not recommend to use unless in specific documented cases and specify security risks.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added this as an option to "alternatives". Right now, I don't think we would have an alternative for this using workspaces.
@pritidesai @afrittoli @pierretasci thanks for the feedback so far! |
This TEP proposes removing volumes from the Task spec in the v1 API, as well as removing volumeMounts and volumeDevices for the container-like fields (Step, StepTemplate, and Sidecar). It does not suggest a preferred solution yet, only alternatives.
- `task.spec.volumes` | ||
- `task.spec.steps.volumeMounts` | ||
- `task.spec.steps.volumeDevices` | ||
- `task.spec.sidecars.volumeMounts` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm less sure we want to remove volumes for sidecars - sidecars could be regular containers that users need to run e.g. a db for an integration test task
[security risks](https://blog.quarkslab.com/kubernetes-and-hostpath-a-love-hate-relationship.html) | ||
they pose. | ||
|
||
#### Support CSI volumes in Workspace Bindings |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CSI volume support is already underway tektoncd/pipeline#4446
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dibyom The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
/lgtm |
This TEP proposes removing volumes from the Task spec in the v1 API, as well as removing
volumeMounts and volumeDevices for the container-like fields (Step, StepTemplate, and Sidecar).
/kind tep