-
Notifications
You must be signed in to change notification settings - Fork 9.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bitnami/mongodb-sharded] Root password creation issue leading to failure to deploy/startup #17042
Comments
Likely related: #13364 |
I did a bit more troubleshooting tonight. I attempted to install the chart in another of my clusters, which differs in configuration (but both use rook/ceph). The same failure occurred. However, I ran a test in the initial cluster, with persistence off. Everything started up as it should. All pods came up, joined the cluster, and were operating successfully without intervention. |
More troubleshooting: Results are the same. |
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. |
keep open |
Hi @sethjones, apologies it took this long to reply; it seems the issue didn't get notify in our board. I've had some problems to reproduce the error but there was an internal task related to #13364 (which had a fix proposed at bitnami/containers#24938) because users both in the PR and issue went MIA. I'll reopen the task and prioritise it so this can get a proper solution. I'll put this ticket |
Was this resolved? I am able to recreate the issue in release v6.6.6. |
Hi I still have the issue, why is this ever happening ? To bypass the "MongoServerError: Authentication failed." I tried to set the auth.enable value to false but this is doing nothing but a brand new error, why a passwordless sharded cluster is not supported if the corresponding flag exists ?
|
Hello @MrWormsy, we are aware the issue is still present. It seems our automations closed this issue by mistake, but the associated internal task is still on our backlog. Thanks for providing more info, we'll leave this issue opened and notify any advances on our side. |
I was unable to reproduce the issue on a GKE cluster but, based on the linked issues, it seems this error can only be reproduced when persistence is enabled and the PV StorageClass uses a "slow" filesystem, which isn't my case so I was unable to reproduce it. As @rafariossaa mentioned on one of the mentioned issued, there's a environment variable ( |
Hi I've just tried setting the parameters to a value of 3600s but I get the same error. I think the error is indeed due to the fact that my server uses HDD instead of SSD. I have no problem running the chart on my personal computer. Thank you for your help. |
Hi all, I guess I have found the root cause of this Authentication failed issue. This happens mostly in slower systems. Reason or Bug:
The problem is in the line
Hence even when it is secondary, i.e. output of Changing the grep check into a more specific one like the following helps to check if the mongodb instance turns into primary and then the root user gets created successfully and Authentication passes.
Any Bitnami coordinators, please help to fix and validate this code and commit this update. Also if there are any other issue threads similar to this, please link to this information. |
Thank you for bringing this issue to our attention. We appreciate your involvement! If you're interested in contributing a solution, we welcome you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here. Your contribution will greatly benefit the community. Feel free to reach out if you have any questions or need assistance. |
Hi @carrodher, Thanks for your appreciation. The bug is not in https://github.com/bitnami/charts, but in https://github.com/bitnami/containers. I have created a pull request (PR) in bitnami/containers. Please help to take this further. |
As of today, I have test deployed chart v7.6.0 with image 7.0.5-debian-12-r2 and the issue has been resolved. Thanks @esasidharan |
Name and Version
bitnami/mongodb-sharded 6.5.3
What architecture are you using?
amd64
What steps will reproduce the bug?
Are you using any custom parameters or values?
Set:
auth.rootPassword
,auth.replicaSetKey
( i have attempted without as well)I have attempted to work around the issues by extending all available timeouts, without success.
I have also attempted enforcing minimum resources of cpu: 8 and memory: 8Gi to ensure that pods were not being resources starved. No change.
What is the expected behavior?
Sharded deployment is created, and starts up using provided username and passwords.
What do you see instead?
Upon initial creation, configsvr enters this state:
Mongos:
Shards 0&1
If I take the additional step to restart the configsvr after initial startup, it will enter a running state and not get stuck in the "Authentication Failed" loop.
After start up the following errors are present from the mongos/shard pods:
Additionally, if I attempt to use the mongosh client on the configsvr I am unable to use the root username and defined password.
It appears that that username creation/modification and set of the root password is not happening.
Additional information
Kubernetes Cluster Information:
Deploying this chart on my desktop via Kind led to a working deployment.
The text was updated successfully, but these errors were encountered: