charts icon indicating copy to clipboard operation
charts copied to clipboard

[bitnami/mongodb] persistenc.existingClaim not entertained

Open busyboy77 opened this issue 2 years ago • 4 comments

Name and Version

bitnami/mongodb-13.1.2

What steps will reproduce the bug?

  1. Helm deployment of bitnami/mongodb with persistenc.existingClaim is never entertained, even when tried with different options.
  2. create a PVC using kubectl apply -f - <<EOF
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mongo-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 25Gi
EOF

List of PVs and PVCs

$ kubectl get pv,pvc
NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                             STORAGECLASS   REASON   AGE
persistentvolume/pvc-3771f3be-9cc3-4606-ba10-4266c1378ed5   128Mi      RWO            Retain           Bound    traefik-ingress/traefik           longhorn                5d19h
persistentvolume/pvc-b83a0014-0fd3-40a9-914d-25f40553cc33   25Gi       RWX            Retain           Bound    default/mongo-pvc                 longhorn                3s

NAME                                            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/mongo-pvc                 Bound    pvc-b83a0014-0fd3-40a9-914d-25f40553cc33   25Gi       RWX            longhorn       5s
  1. the config parameters are
helm install \
--namespace=default \
--set auth.enabled=false \
--set readinessProbeenabled=true \
--set readinessProbe.failureThreshold=20 \
--set readinessProbe.initialDelaySeconds=10  \
--set readinessProbe.periodSeconds=20 \
--set readinessProbe.successThreshold=1  \
--set readinessProbe.timeoutSeconds=40 \
--set livenessProbe.enabled=true \
--set livenessProbe.failureThreshold=25 \
--set livenessProbe.initialDelaySeconds=30 \
--set livenessProbe.periodSeconds=20 \
--set livenessProbe.successThreshold=1 \
--set livenessProbe.timeoutSeconds=40 \
--set architecture=standalone \
--set resources.limits.cpu=1100m \
--set resources.limits.memory=8Gi \
--set resources.requests.cpu=1100m \
--set resources.requests.memory=8Gi \
--set useStatefulSet=true \
--set persistence.enabled=true \
--set persistenc.existingClaim=mongo-pvc \
--set persistenc.accessModes[0]=ReadWriteMany \
--set persistenc.storageClass=longhorn \
--set volumePermissions.enabled=true \
--set persistence.size=25Gi \ 
mongo bitnami/mongodb
  1. No error is returned.

Are you using any custom parameters or values?

--namespace=default \
--set auth.enabled=false \
--set readinessProbeenabled=true \
--set readinessProbe.failureThreshold=20 \
--set readinessProbe.initialDelaySeconds=10  \
--set readinessProbe.periodSeconds=20 \
--set readinessProbe.successThreshold=1  \
--set readinessProbe.timeoutSeconds=40 \
--set livenessProbe.enabled=true \
--set livenessProbe.failureThreshold=25 \
--set livenessProbe.initialDelaySeconds=30 \
--set livenessProbe.periodSeconds=20 \
--set livenessProbe.successThreshold=1 \
--set livenessProbe.timeoutSeconds=40 \
--set architecture=standalone \
--set resources.limits.cpu=1100m \
--set resources.limits.memory=8Gi \
--set resources.requests.cpu=1100m \
--set resources.requests.memory=8Gi \
--set useStatefulSet=true \
--set persistence.enabled=true \
--set persistenc.existingClaim=mongo-pvc \
--set persistenc.accessModes[0]=ReadWriteMany \
--set persistenc.storageClass=longhorn \
--set volumePermissions.enabled=true \
--set persistence.size=25Gi \ 

What is the expected behavior?

helm chart should create use an existing PVC, however the default PVC+PV set is created and the persistenc.existingClaim is completely ignored.

$ kubectl get pv,pvc
NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                             STORAGECLASS   REASON   AGE
persistentvolume/pvc-22406c0b-e7d2-4da0-ae5a-117ed75e0c0a   25Gi       RWO            Retain           Bound    default/datadir-mongo-mongodb-0   longhorn                12m
persistentvolume/pvc-3771f3be-9cc3-4606-ba10-4266c1378ed5   128Mi      RWO            Retain           Bound    traefik-ingress/traefik           longhorn                5d19h
persistentvolume/pvc-b83a0014-0fd3-40a9-914d-25f40553cc33   25Gi       RWX            Retain           Bound    default/mongo-pvc                 longhorn                3s

NAME                                            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/mongo-pvc                 Bound    pvc-b83a0014-0fd3-40a9-914d-25f40553cc33   25Gi       RWX            longhorn       5s

What do you see instead?

the default PV and PVC are created and used instead.

Additional information

I have given it a fake ExistingClaim and it still goes to create on its own.

busyboy77 avatar Sep 16 '22 14:09 busyboy77

Hi,

If I'm not mistaken, the use of an existing PVC is only meant for the standalone mode. If you use StatefulSets it will create a PVC per instance as sharing the same PVC would lead to unexpected issues.

javsalgar avatar Sep 19 '22 09:09 javsalgar

I'm also using --set architecture=standalone so the option should take over the existing PVC/PV.

using architecture as standalone and useStatefulSet at the same time should be negated then or at least using existingClaim should give error or vice a versa

busyboy77 avatar Sep 19 '22 10:09 busyboy77

disabling useStatefulSet doesn't make any sense. Its still going to create its own PVC/PV couple.

busyboy77 avatar Sep 19 '22 14:09 busyboy77

I have even disabled all architecture options and just relying on standard helm install with only existingClaim and it doesn't work, always creating a new PVC+PV

busyboy77 avatar Sep 19 '22 14:09 busyboy77

Thanks for reporting this issue. Would you like to contribute by creating a PR to solve the issue? The Bitnami team will be happy to review it and provide feedback. Here you can find the contributing guidelines.

carrodher avatar Sep 26 '22 09:09 carrodher

hi I'm not sure what is the way to open a PR . Can someone please guide me and I'll be happy to do that.

Regards, NMR

On Mon, Sep 26, 2022 at 2:08 PM Carlos Rodríguez Hernández < @.***> wrote:

Thanks for reporting this issue. Would you like to contribute by creating a PR to solve the issue? The Bitnami team will be happy to review it and provide feedback. Here https://github.com/bitnami/charts/blob/master/CONTRIBUTING.md you can find the contributing guidelines.

— Reply to this email directly, view it on GitHub https://github.com/bitnami/charts/issues/12463#issuecomment-1257727885, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEVPTEM6KNAKZYJNHURYVBTWAFRYPANCNFSM6AAAAAAQOLYZDM . You are receiving this because you authored the thread.Message ID: @.***>

-- Nasir Mahmood

busyboy77 avatar Oct 06 '22 17:10 busyboy77

You can find the instructions in the CONTRIBUTING guidelines and some generic instructions in the GitHub documentation itself, see https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request

carrodher avatar Oct 07 '22 05:10 carrodher

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

github-actions[bot] avatar Oct 23 '22 01:10 github-actions[bot]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.

github-actions[bot] avatar Oct 28 '22 01:10 github-actions[bot]