camel-k icon indicating copy to clipboard operation
camel-k copied to clipboard

RFE to allow dynamic creation of Persistent Volumes from storage classes

Open ramgopireddy opened this issue 3 years ago • 15 comments

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?

ramgopireddy avatar Feb 07 '22 21:02 ramgopireddy

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.

haanhvu avatar Mar 29 '22 03:03 haanhvu

Thanks for your interest.

squakez avatar Mar 29 '22 07:03 squakez

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 ?

haanhvu avatar Apr 17 '22 17:04 haanhvu

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 avatar Apr 18 '22 09:04 squakez

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?

haanhvu avatar Apr 18 '22 09:04 haanhvu

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 avatar Apr 18 '22 10:04 squakez

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 avatar Apr 20 '22 08:04 haanhvu

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

squakez avatar Apr 20 '22 12:04 squakez

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!

github-actions[bot] avatar Jul 21 '22 00:07 github-actions[bot]

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

squakez avatar Feb 17 '23 09:02 squakez