carrodher
commented
6 days ago Thank you for bringing this issue to our attention. We appreciate your involvement! If you're interested in contributing a solution, we welcome you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.
Your contribution will greatly benefit the community. Feel free to reach out if you have any questions or need assistance.
Name and Version
bitnami/kube-prometheus 9.0.5
What is the problem this feature will solve?
We have observed the issue in Chart version 9.0.5, but that behavior is probably still there even in the newest Chart version.
In our org, we use shared k8s clusters whereby users get access only to their namespace. Cluster resources are not accessible, as e.g. relevant here, there is no access to get the available storageClasses listed.
Anyway, the deployment of apps via Helm Charts that need persistent storage works:
With the deployment of the Prometheus Operator (bitnami/kube-prometheus) we are facing the following problem regarding specifying a certain storageClass in the values file.
However, due to storageClass checking done by the Prometheus Operator, the deployment of a Prometheus instance fails.
prometheus-operator pod log:
Because of the storageClass check we stick to the default storage provisioner.
What is the feature you are proposing to solve the problem?
Add a parameter in the values file to be able to disable the storageClass check.
What alternatives have you considered?
Remove the storageClass check at all. If there is no valid storageClass specified, the deployment will fail anyway with the difference that the relevant log message will be found in another resource.