argoproj / argoproj/argo-workflows
Override volume used by workflow template
- Dominant language
- Go
- Stars
- 17k
- Forks
- 3.7k
- Avg merge
- 1d 20h
- Merged PRs (30d)
- 138
Description
# Summary
Make it possible to override volume and volume claim templates definition in a workflow spec referencing external templates.
# Use Cases
In case of building library of templates sometimes it will be convenient to allow parent workflow definition to override volume definition:
* need to change volume parameters (e.g. storage class, size)
* decide wether to use volume data in subsequent steps or not
How it might look like:
1. Template definition
```yaml
apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
name: template-with-reference-to-volume
spec:
arguments:
templates:
- name: print-mount
volumes:
- name: workdir
emptyDir: { }
container:
image: docker/whalesay:latest
command: [mount]
volumeMounts:
- name: workdir
mountPath: /mnt/vol
```
2. Workflow definition:
```yaml
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
generateName: volumes-pvc-
spec:
entrypoint: volumes-pvc-example
volumeClaimTemplates:
- metadata:
name: workdir
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
templates:
- name: volumes-pvc-example
steps:
- - name: print
templateRef:
name: template-with-reference-to-volume
template: print-mount
```
As alternative, volumes might be configured optional and not require volume definition presence in template or workflow spec.
---
**Message from the maintainers**:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.
Contributor guide
Research direction
Start by tracing how a workflow's templateRef is resolved and how volumes and volumeClaimTemplates are handled in the referenced template and parent workflow specs. Confirm the intended precedence and optional-volume behavior from the examples; done means a parent workflow can override those definitions when referencing an external template.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- backend, infrastructure
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100