[bitnami/argo-workflows] pods forbidden cannot patch resource "pods"

jgagnon44 commented 2 weeks ago

Name and Version

bitnami/charts/argo-workflows 9.1.3

What architecture are you using?

None

What steps will reproduce the bug?

In my local Docker Desktop Kubernetes cluster context, I installed this Helm chart as follows:

$ kubectl config current-context
docker-desktop

$ helm install jmg-test . -n argo-workflows --create-namespace -f local-values.yaml
NAME: jmg-test
LAST DEPLOYED: Tue Jun 18 12:51:47 2024
NAMESPACE: argo-workflows
STATUS: deployed
REVISION: 1
TEST SUITE: None

Are you using any custom parameters or values?

argo-workflows:
  controller:
    serviceAccount:
      create: true
    workflowNamespaces:
      - argo-workflows

  server:
    auth:
      mode: server
    serviceAccount:
      create: true

  workflows:
    serviceAccount:
      create: true

  postgresql:
    enabled: false

  mysql:
    enabled: false

  externalDatabase:
    enabled: false

  ingress:
    enabled: true
    hostname: argo.devhost.beast-code-demo.com
    ingressClassName: nginx

What is the expected behavior?

I'm not familiar with Argo Workflows or how the application is intended to be used. I simply opened the app and attempted to create a new workflow in the namespace I set up and provided. After a few moments, an error message was displayed. I then checked the app pod logs to see if there was anything to see.

What do you see instead?

The chart appears to have been successfully deployed and I can bring up the app (by port forwarding, not sure why ingress is not working) and attempt to create a new workflow in the namespace I have set up. I'm using the Lens application to watch the activity on the cluster. I can see a new pod created, but it quickly dies and disappears. When I look in the pod log for the controller, I see various error messages. See the attached log.

jmg-test-argo-workflows-controller-846d9fddf5-xq5xx.log

Additional information

I captured the output from installing the Helm chart with the --debug flag set.

debug.log

carrodher commented 2 weeks 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.

jgagnon44 commented 2 weeks ago

The original reporter of the issue found and made some tweaks to his chart values and it appears to have resolved this issue. We can now create and successfully execute a workflow.

What seems to have made the difference was adding automountServiceAccountToken: true under the config wherever a service account is configured. For example:

  workflows:
    serviceAccount:
      create: true
      automountServiceAccountToken: true

jgagnon44 commented 2 weeks ago

There are, however, still some interesting entries in the server pod log. I don't think they have anything directly to do with what we have been doing, but wanted to mention them in any case.

Look for the word "failed" in the log.

argo-workflows-server-bc44b586b-hvrvz.log

bitnami / charts