Requesting support for the dataSource field when creating a PersistentVolumeClaim (PVC) using the KFP Python SDK DSL container_component CreatePVC. This feature would enable users to create PVCs with pre-populated data, aligning with Kubernetes capabilities for cloning or restoring PVCs from existing volumes or snapshots.
What is the use case or pain point?
The dataSource field is essential for workflows that depend on pre-initialized volumes, such as restoring a snapshot for processing or cloning an existing volume for parallel workflows.
Is there a workaround currently?
Use a custom component task that invokes the kubernetes library and creates a PVC with a dataSource from a VolumeSnapshot.
Proposed changes
Extend the PVC creation API in the KFP Python SDK to include the optional dataSource parameter, reflecting the Kubernetes PersistentVolumeClaimSpec.
Feature Area
/area backend /area sdk
What feature would you like to see?
Requesting support for the dataSource field when creating a PersistentVolumeClaim (PVC) using the KFP Python SDK DSL container_component
CreatePVC
. This feature would enable users to create PVCs with pre-populated data, aligning with Kubernetes capabilities for cloning or restoring PVCs from existing volumes or snapshots.What is the use case or pain point?
The dataSource field is essential for workflows that depend on pre-initialized volumes, such as restoring a snapshot for processing or cloning an existing volume for parallel workflows.
Is there a workaround currently?
Use a custom component task that invokes the
kubernetes
library and creates a PVC with a dataSource from a VolumeSnapshot.Proposed changes
Extend the PVC creation API in the KFP Python SDK to include the optional dataSource parameter, reflecting the Kubernetes PersistentVolumeClaimSpec.
Love this idea? Give it a 👍.