RFE to allow dynamic creation of Persistent Volumes from storage classes
We would like the option to dynamically create a persistent volume using the operator instead of having to create a Persistent Volume first and using it to mount on the integration. Is it possible to extend the Mount trait to allow provisioning of the PV from a storage class as well?
Hi @astefanutti @squakez, I would like to work on this issue. Could you assign it to me? I'm studying the codebase and may ask questions later.
Thanks for your interest.
From what I see here: https://github.com/apache/camel-k/blob/cb9b886f964f398e14a02965896267f07190eec2/pkg/trait/trait_types.go#L566-L592 The mount trait will just mount the PVC, no matter if the PVC is statically or dynamically provisioned.
Is that right @squakez @astefanutti ?
The mount trait will just mount the PVC, no matter if the PVC is statically or dynamically provisioned.
Is that right @squakez @astefanutti ?
Yes, that's my understanding too.
The mount trait will just mount the PVC, no matter if the PVC is statically or dynamically provisioned. Is that right @squakez @astefanutti ?
Yes, that's my understanding too.
@squakez if that's the case, then this issue already had a solution?
I think the idea of the issue is to have the trait accepting the parameters to create the PVC on the fly. As an example, we can think the following kamel run -t mount.storage-class=vpc-block -t mount.storage-request=30Gi -t mount.storage-mode=ReadWriteOnce ... which is in charge to create the PVC on the cluster, and later, mount accordingly on the Integration.
I think the idea of the issue is to have the trait accepting the parameters to create the PVC on the fly. As an example, we can think the following
kamel run -t mount.storage-class=vpc-block -t mount.storage-request=30Gi -t mount.storage-mode=ReadWriteOnce ...which is in charge to create the PVC on the cluster, and later, mount accordingly on the Integration.
@squakez should we have another trait for this? I mean, the mount trait should just do what it does: mount the volume. If we need to "create" the volume, should we have another trait for it, like the pvc trait?
@haanhvu we may reason about that for sure. In any case, the business logic would be pretty similar and you'd need to related the mount trait anyway. IMO, we should do a first development within the mount trait, and later figure it out if it makes sense to have a separate trait for that.
This issue has been automatically marked as stale due to 90 days of inactivity. It will be closed if no further activity occurs within 15 days. If you think that’s incorrect or the issue should never stale, please simply write any comment. Thanks for your contributions!
We could leverage the work done in https://github.com/apache/camel-k/pull/4025/commits/f82d1e296c4bcd398e03e75764443e0acc6083eb to dynamically create a volume based on StorageClasses