mariadb-operator/mariadb-operator

[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

  1. kubectl apply -f mariadb_repl_maxscale.yaml
  2. 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!

Fixed by #634