When the field "spec.database.storageClassName" is omitted in Kubegres YAML, Kubegres operator should assign the default storageClass to the deployed PostgreSql cluster #18
Description
Activity
Thank you for your message and for providing those details.
I am going to investigate this issue and come back to you.
From the spec, the field "storageClassName" is a mandatory field, please see that field in the table in the page:
https://www.kubegres.io/doc/properties-explained.htmlHowever, in the logs it should not display panics but rather a validation message such as:
"In the Resources Spec the value of 'spec.database.storageClassName' is undefined. Please set a value otherwise this operator cannot work correctly."
Indeed, I missed that part! However, I'd suggest to make it optional because the PVC's storageClassName field is optional too, and otherwise there is now way to reference the default storageclass. I'd gladly open another ticket independently of this issue and contribute that change.
Reacted by Alex AricaThank you for your message. As you suggested, we can make storageClassName optional.
If that field is not provided, I can add a logic to identify the name of the default "storageClassName" in a Kubernetes cluster and set it automatically.
I added this feature to the roadmap.
If that field is not provided, I can add a logic to identify the name of the default "storageClassName" in a Kubernetes cluster and set it automatically.
I believe you will not have to set anything at all. You can omit the storageClassName property of your PVC, and it will pick the default storage class.
https://kubernetes.io/docs/tasks/administer-cluster/change-default-storage-class/
Depending on the installation method, your Kubernetes cluster may be deployed with an existing StorageClass that is marked as default. This default StorageClass is then used to dynamically provision storage for PersistentVolumeClaims that do not require any specific storage class.
This is usually what I want when deploying PostgreSQL: The default storage class tends to be durable but fast enough storage.
Reacted by Alex AricaThank you for your recommendation. I will take that approach which simplifies the feature.
Thank you for your great feedback.
Is there anything preventing you from running the command below to get the name of the default storage class in your Kubernetes cluster?
kubectl get scAnd then set the default storage class name in your Kubegres resource YAML when creating a cluster of PostgreSql?
Nothing whatsoever :). And that's what I did to try out Kubegres. However, I would prefer to have as little information about the cluster I am running on in my YAML resources. This makes them more portable, i.e. there is less stuff to edit/replace for moving it from one cluster to another.
We are using Kubegres in large systems and in those type of Kubernetes clusters have multiple storage classes based on latency capabilities. We tend to set the storage classes manually by selecting the ones with the lowest latencies. The default one is not always the fastest.
In your case, I suppose you are working with systems where latency is not the main factor and you want to setup a cluster quickly where the default settings are acceptable.
The argument about portability is compelling in your case. I think that's an important factor. It is good that you suggested this feature because it highlights additional use cases where Kubegres can fill some gaps.
I am working on this feature and will commit a beta version tomorrow. I will let you know once it is available, and I would be grateful if you can test it as well?
Once you confirm things are working fine on your side, I will make a final commit with acceptance tests and create a release/tag.
Reacted by Oliver KuckertzWill do, thank you very much for looking into this!
Reacted by Alex Arica- changed the title
[-]Segfault when spec.database.storageClassName is omitted[/-][+]When spec.database.storageClassName is omitted in YAML, Kubegres should assign the default one to the deployed PosgreSql cluster[/+]on Jun 8, 2021 - added a commit that references this issue
on Jun 8, 2021 - changed the title
[-]When spec.database.storageClassName is omitted in YAML, Kubegres should assign the default one to the deployed PosgreSql cluster[/-][+]When spec.database.storageClassName is omitted in YAML, Kubegres should assign the default storageClass to the deployed PosgreSql cluster[/+]on Jun 8, 2021 I made the changes and added new acceptance tests in GIT main.
You can install beta Kubegres version 1.6, as follows:
kubectl apply -f https://raw.githubusercontent.com/reactive-tech/kubegres/main/kubegres.yamlOnce you are happy with your tests, please let me know and I will create a new release/tag and update the documentation.
Seems to work 👌 . What I tested was that 1) the segfault is fixed by inserting the objects that would previously crash, observe the crash, and then updating kubegres. It correctly deployed PostgreSQL afterwards.
I 2) checked that it would deploy PostgreSQL with my default storage class "vsan-mirror" when omitting storageClassName, which worked correctly.
Reacted by Alex AricaReacted by Alex Arica- changed the title
[-]When spec.database.storageClassName is omitted in YAML, Kubegres should assign the default storageClass to the deployed PosgreSql cluster[/-][+]When the field "spec.database.storageClassName" is omitted in Kubegres YAML, Kubegres operator should assign the default storageClass to the deployed PostgreSql cluster[/+]on Jun 9, 2021 I created a new tag/release 1.6 here:
https://github.com/reactive-tech/kubegres/releasesTo install Kubegres 1.6:
kubectl apply -f https://raw.githubusercontent.com/reactive-tech/kubegres/v1.6/kubegres.yamlI updated the documentation pages, as follows:
- new version 1.6 added in: Getting started page
- removed storageClasName from the Kubegres YAML example in: Getting started page
- updated the table listing all properties where storageClassName is set as optional: All properties explained
Please close this ticket if you are happy with the changes.
Thank you for your suggestions and your help!
Thanks very much :) I updated to the version you mentioned w/o issues.
Reacted by Alex Arica- added a commit that references this issue
on Aug 10, 2024
Hi, I found that kubeges's controller segfaults and stays down when I omit the storageClassName property. It recovers once the offending Kubegres object is removed.
Expected behavior: Kubegres would request PVCs with the default storage class, i.e. simply omit the storageClassName field when generating its PVCs.
Steps to reproduce: Apply the following yaml:
And observe how the manager container of kubegres-controller-manager panics immediately: