Closed braghettos closed 1 month ago
The issue may not be directly related to the Bitnami container image/Helm chart, but rather to how the application is being utilized, configured in your specific environment, or tied to a specific scenario that is not easy to reproduce on our side.
If you think that's not the case and are 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.
Suppose you have any questions about the application, customizing its content, or technology and infrastructure usage. In that case, we highly recommend that you refer to the forums and user guides provided by the project responsible for the application or technology.
With that said, we'll keep this ticket open until the stale bot automatically closes it, in case someone from the community contributes valuable insights.
@carrodher I think it is related to the Helm chart, in particular to the readiness script, because it is trying to make a commit with a username that does not exist because the RBAC is disabled (as made possible via the same Helm chart). I will check the script's content and give you feedback.
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.
Name and Version
bitnami/etcd 10.2.7
What architecture are you using?
amd64
What steps will reproduce the bug?
helm install etcd-test krateo/etcd -n krateo-system --set auth.rbac.create=false
Are you using any custom parameters or values?
--set auth.rbac.create=false
What is the expected behavior?
Etcd is running and readiness probe is satisfied.
What do you see instead?
When I describe etcd pod:
Additional information
This issue is not happening in kind. I found this issue on an AKS cluster.