Please add an option to the WithPersistentVolume APIs to specify a volume name when configuring persistent storage.
Problem
Current behavior appears focused on dynamic provisioning. In some environments, we need to bind to a pre-existing persistent volume already present in the cluster (for example: manually provisioned storage, migrations, or policy-constrained environments).
Without a way to set volume name, it’s hard to reliably target an existing volume and avoid dynamic allocation.
Proposed change
Add an overload or option on WithPersistentVolume APIs to allow setting a Kubernetes volume name (or equivalent binding field), so Aspire can request/use a pre-existing volume.
Example (illustrative):
C#
.WithPersistentVolume(volumeName: "existing-shared-pv")
Expected outcome
Bind Aspire resources to specific, already-provisioned volumes.
Better support for static provisioning and enterprise cluster constraints.
Improved migration/interoperability with existing Kubernetes storage setups.
Please add an option to the
WithPersistentVolumeAPIs to specify a volume name when configuring persistent storage.Problem
Current behavior appears focused on dynamic provisioning. In some environments, we need to bind to a pre-existing persistent volume already present in the cluster (for example: manually provisioned storage, migrations, or policy-constrained environments).
Without a way to set volume name, it’s hard to reliably target an existing volume and avoid dynamic allocation.
Proposed change
Add an overload or option on WithPersistentVolume APIs to allow setting a Kubernetes volume name (or equivalent binding field), so Aspire can request/use a pre-existing volume.
Example (illustrative):
C#
.WithPersistentVolume(volumeName: "existing-shared-pv")Expected outcome