-
Notifications
You must be signed in to change notification settings - Fork 451
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature: add support to set folderName on PVC #384
Comments
It would be great to consider also implement it in the automatic provisioner. Smething like use the namespace of the pvc so the PVs will automatically sorted in folders named by the namespace. In my scenario I have four k3s-nodes in a lxc container runnig on a proxmox server. They all share one datadir where local-path autoprovision the pvs. This datadir is quit confusing because of the flat use of the volid as the name in that directory. |
Seconding this. I finished bootstrapping a k3s cluster for a client and getting to the storage paths is a bit confusing. Not impossible, but it very much is not a whole lot of fun. For my own deployment at home, I plan to use the shared filesystem together with a permanent rclone mount, which I access from many locations. Being able to "predict" the name would be very helpful here when I need to dig into log files or the like. Thanks! |
To reconsider this point, for example, we can mount different disks for different PVs to achieve IO isolation |
@derekbit PTAL |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
This issue was closed because it has been stalled for 5 days with no activity. |
Whenever a PV is dynamically created, a directory is generated with the following name
$persistentVolumeName_$persistentVolumeClaimNamespace_$persistentVolumeClaimName
.It would be helpful if we can decide what the directory name of the generated directory would be up front. This could be done by setting an annotation on the persistent volume claim.
This logic is included in the following PR:
#372
The text was updated successfully, but these errors were encountered: