[Bug] Unable to Start Maxscale Pod After add StorageClassName in MaxScale Config
Closed this issue · 2 comments
Describe the bug
When I add the storageClassName in the MaxScale Config . The operator approved my modification to the storage configuration, but when I changed the storageClass, the pod failed to start. Upon investigation, I found that the pod was missing essential parameters in the PersistentVolumeClaim (PVC) configuration, which resulted in the failure to start.
my yaml config is:
apiVersion: k8s.mariadb.com/v1alpha1
kind: MariaDB
metadata:
name: mariadb-repl
spec:
rootPasswordSecretKeyRef:
name: mariadb
key: root-password
storage:
size: 1Gi
storageClassName: xxx
replicas: 3
# point to an existing MaxScale instance. Doing this will delegate tasks such as primary failover to MaxScale.
# maxScaleRef:
# name: maxscale-repl
# provision a MaxScale instance and set 'spec.maxScaleRef' automatically.
maxScale:
enabled: true
config:
volumeClaimTemplate:
storageClassName: xxx
kubernetesService:
type: LoadBalancer
metadata:
annotations:
metallb.universe.tf/loadBalancerIPs: 172.18.0.219
guiKubernetesService:
type: LoadBalancer
metadata:
annotations:
metallb.universe.tf/loadBalancerIPs: 172.18.0.230
connection:
secretName: mxs-repl-conn
port: 3306
replication:
enabled: true
service:
type: LoadBalancer
metadata:
annotations:
metallb.universe.tf/loadBalancerIPs: 172.18.0.120
primaryService:
type: LoadBalancer
metadata:
annotations:
metallb.universe.tf/loadBalancerIPs: 172.18.0.130
secondaryService:
type: LoadBalancer
metadata:
annotations:
metallb.universe.tf/loadBalancerIPs: 172.18.0.131
I think the reason in below code:
func (m *MaxScaleConfig) SetDefaults(mxs *MaxScale) {
if reflect.ValueOf(m.VolumeClaimTemplate).IsZero() {
m.VolumeClaimTemplate = VolumeClaimTemplate{
PersistentVolumeClaimSpec: corev1.PersistentVolumeClaimSpec{
Resources: corev1.VolumeResourceRequirements{
Requests: corev1.ResourceList{
"storage": resource.MustParse("100Mi"),
},
},
AccessModes: []corev1.PersistentVolumeAccessMode{
corev1.ReadWriteOnce,
},
},
}
}
...
}
Expected behaviour
Steps to reproduce the bug
- kubectl apply -f mariadb_repl_maxscale.yaml
- kubetl describe sts mariadb-repl-maxscale
Debug information
- Related sts events:
statefulset-controller create Pod mariadb-repl-maxscale-0 in StatefulSet mariadb-repl-maxscale failed error: failed to create PVC storage-mariadb-repl-maxscale-0: PersistentVolumeClaim "storage-mariadb-repl-maxscale-0" is invalid: [spec.accessModes: Required value: at least 1 access mode is required, spec.resources[storage]: Required value]
Environment details:
- Kubernetes version: [1.22]
- Kubernetes distribution: [KIND]
- mariadb-operator version: [0.0.28]
- Install method: [helm]
- Install flavor: [custom]
Additional context
Hey there @luohaha3123 ! Thanks for bringing this up.
Our current defaulting strategy for the MaxScale
's volumeClaimTemplate
does not handle partial defaults, it is an all or nothing. That being said, it is not ideal, we should handle cases where, as you described, the user only provides the storageClassName
but not the storage requests.
Ideally, we should expand the MaxScaleConfig
's SetDefaults
method to cover partial defaults and add some test cases. Contributions are welcome!