-
Notifications
You must be signed in to change notification settings - Fork 25
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
PersistentVolumeClaim and PersistentVolume Parameters (--extra-create-metadata
)
#205
Comments
Thank you for the idea. In kubernetes, PV does not belong to the PVC, you can change/recreate PVC with the same PV. I noticed that recreate/rename PVC in kubernetes very often case. Adding the namespace or PVC name to the PV name could cause confusion for operators in the future. Do you have any ideas on how we could address this issue? |
Hi @sergelogvinov ,
there are no tags, but there are They can be get/set using the
API Doc can be found here. Unfortunately the availability of As we are using Linstor with
Next "problem" is, that notes are not shown in the proxmox UI.
This seems true either, unfortunately :-)
Fair point. One could make this feature optional and inform about this fact in the documentation. Or if notes would have been available in general, each creation/rename operation could append some sort of log entry to the PV notes field. As I digged deeper into this topic, I understand that this wont make to much sense until proxmox provides a better way regarding either the naming of PVs or adds a tagging system to the resources. |
Yes, it's sad news. |
Add Support for PersistentVolumeClaim and PersistentVolume Parameters (
--extra-create-metadata
)Description
Since v1.6.0+ Kubernetes CSI the flag
--extra-create-metadata
exists which passes the following information to aCreateVolumeRequest
:csi.storage.k8s.io/pvc/name
csi.storage.k8s.io/pvc/namespace
csi.storage.k8s.io/pv/name
Here you can see the corresponding merge request.
This should allow something like:
vm-9999-pvc-3b76c8aa-1024-4f2e-88ca-8b3e27e27f65-namespace-pvc_name-pv_name
orvm-9999-pvc-namespace-pvc_name-pv_name-3b76c8aa-1024-4f2e-88ca-8b3e27e27f65
which would make it a lot easier to see which VM disk is belongs to a Kubernetes resource.What do you think?
Congratulations for this great Proxmox plugin!
The text was updated successfully, but these errors were encountered: