charts
charts copied to clipboard
[bitnami/mongodb] persistenc.existingClaim not entertained
Name and Version
bitnami/mongodb-13.1.2
What steps will reproduce the bug?
- Helm deployment of bitnami/mongodb with
persistenc.existingClaim
is never entertained, even when tried with different options. - 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
- 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
- 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.
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.
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
disabling useStatefulSet
doesn't make any sense. Its still going to create its own PVC/PV couple.
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
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.
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
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
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.
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.