External volumes #325
External volumes #325
Conversation
Support the use case of mounting an existing secret, configmap, or persistent volume into a devfile component by adding a field 'external' to volume components. When not empty, the volume component is taken as referring to some existing resource that should be mounted to components as required. Signed-off-by: Angel Misevski <amisevsk@redhat.com>
Signed-off-by: Angel Misevski <amisevsk@redhat.com>
amisevsk
requested review from
kadel,
davidfestal,
skabashnyuk and
johnmcollier
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: amisevsk The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
components:
- name: cfg
volumes:
external:
name: my-app-cfg
type: secretLooks simple but it makes sense to think if we want to support advanced parameters for each of type, like optional, items for configmap and secret, and readonly for storage.
If we want, then we may want to go the following way:
components:
- name: cfg
volumes:
external:
secret:
name: my-app-cfg # can be secretName if we follow k8s
optional: true # optional is optional =)
items: ...the only drawback - one more nesting level
|
|
||
| const ( | ||
| // PersistentVolumeType specifies persistent storage, e.g. a PersistentVolumeClaim | ||
| PersistentVolumeType ExistingVolumeType = "persistent" |
There was a problem hiding this comment.
If this is always going reference PVC would it be better to go with full name? persistentvolumeclaim?
There was a problem hiding this comment.
I prefer the abstraction that persistent gives (plus it's shorter), but I'm fine either way. In general, tying our API 1-1 with kubernetes makes the whole thing feel like a weird indirection layer rather than an API.
From a k8s perspective, yes, the fields are exclusive -- most of the top-level volume fields are invalid if |
|
@amisevsk: PR needs rebase. 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. |
What does this PR do?
This PR is half of #310 (support for "external" volumes). It adds support for mounting existing resources (e.g. configmaps, secrets, or persistent volumes) into devfile components without the implicit assumption that they're defined by the devfile itself. Use cases are:
I've separated it out as this is a change we should consider carefully -- referring to volumes that are assumed to exist on the cluster makes devfiles less portable. Without a defined way of handling volumes we can't find, we risk e.g. my devfile not being compatible with your cluster (unless you happen to have the same configmaps/secrets defined). (Thanks @l0rd for pointing this out.)
What issues does this PR fix or reference?
Half of #310
Is your PR tested? Consider putting some instruction how to test your changes
N/A