PVC remains in Pending state when deploying MongoDB with Percona Server for MongoDB Operator it does not automatically set the default storageClassName

[AshishThakur10]

Report

Hello,

I am experiencing an issue where the Persistent Volume Claim (PVC) remains in the Pending state when deploying MongoDB using the Percona Server for MongoDB Operator. The PVC does not automatically get bound to a Persistent Volume (PV), despite having a default storage class configured in the Kubernetes cluster.

Steps to Reproduce

1. Deploy MongoDB using the Percona Server for MongoDB Operator with the following configuration:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: p-pm-mongodbtest
spec:
  project: default
  destination:
    namespace: p-pm-mongodbtest
    server: https://kubernetes.default.svc
  syncPolicy:
    automated: {}
    syncOptions:
      - CreateNamespace=true
  source:
    repoURL: https://charts.rock8s.com
    chart: mongodb
    targetRevision: "1.15.0"
    helm:
      values: |
        config:
          debug: false
          istio: false
          mongodb:
            replicas: 1
            resources:
              requests:
                cpu: 300m
                memory: 0.5G
              limits:
                cpu: 300m
                memory: 0.5G
          pmm:
            enabled: false
        service:
          mongodb:
            type: ClusterIP
            tls:
              enabled: false
        persistence:
          accessMode: ReadWriteOnce
          size: 1Gi
          storageClassName: ""
          kanister:
            enabled: false
            schedule: '0 0 * * *'

2. Check the status of the PVC:

kubectl get pvc -n p-pm-mongodbtest

Expected Results

The PVC should be bound to a PV and not remain in the Pending state.

Actual Results

The PVC remains in the Pending state and is not bound to any PV. Here are the details of the PVC:

kubectl describe pvc mongod-data-mongodb-rs0-0 -n p-pm-mongodbtest

Name:          mongod-data-mongodb-rs0-0
Namespace:     p-pm-mongodbtest
StorageClass:  
Status:        Pending
Volume:        
Labels:        app.kubernetes.io/component=mongod
               app.kubernetes.io/instance=mongodb
               app.kubernetes.io/managed-by=percona-server-mongodb-operator
               app.kubernetes.io/name=percona-server-mongodb
               app.kubernetes.io/part-of=percona-server-mongodb
               app.kubernetes.io/replset=rs0
Annotations:   <none>
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      
Access Modes:  
VolumeMode:    Filesystem
Used By:       mongodbtest-rs0-0
Events:        <none>

Additional Information

kubectl get storageclass

NAME                      PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
default                   kubernetes.io/aws-ebs   Delete          Immediate              false                  190d
efs-sc                    efs.csi.aws.com         Delete          Immediate              false                  142d
gp2                       kubernetes.io/aws-ebs   Delete          Immediate              false                  190d
kops-csi-1-21 (default)   ebs.csi.aws.com         Delete          WaitForFirstConsumer   true                   190d
kops-ssd-1-17             kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   true                   190d

Workaround

As a temporary workaround, I manually specified the storage class in the PVC definition, which allowed it to get bound:

spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 4Gi
  storageClassName: "kops-csi-1-21"
  volumeMode: Filesystem

I would appreciate any guidance on how to resolve this issue and ensure the PVC gets bound automatically without needing to specify the storage class explicitly.

Thank you!

More about the problem

PCV

Versions

Kubernetes: v1.22.0
Operator: Percona Server for MongoDB Operator 1.15.0
Database: Percona Server for MongoDB 4.4.6-8

Client Version: v1.30.1
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.26.11

[hors]

@AshishThakur10 did you set this option storageClassName: ""? If you do not want to specify it at all, you should not set it and in this case it will use the default SC