argo-workflows
argo-workflows copied to clipboard
Patch workflowtasksets/status is not enabled by default. Http templates don't work.
Checklist
- [x] Double-checked my configuration.
- [x] Tested using the latest version.
- [x] Used the Emissary executor.
Summary
What happened/what you expected to happen? While trying to help someone in slack, we noticed that (this example)[https://raw.githubusercontent.com/argoproj/argo-workflows/master/examples/http-hello-world.yaml] does not run on workflows 3.3.8 out of the box. You have to add to the supplied rbac to make it work.
The argo-aggregate-to-admin clusterrole in (the official release)[https://github.com/argoproj/argo-workflows/releases/download/v3.3.8/install.yaml] is missing the ability to patch workflowtasksets/status
.
Slack conversation: https://cloud-native.slack.com/archives/C01QW9QSSSK/p1658392626200229
What version are you running? 3.3.8
Diagnostics
Paste the smallest workflow that reproduces the bug. We must be able to run the workflow. https://raw.githubusercontent.com/argoproj/argo-workflows/master/examples/http-hello-world.yaml
The workflow's pods that are problematic:
level=warning msg="Non-transient error: workflowtasksets.argoproj.io \"http-template-jpfb5\" is forbidden: User \"system:serviceaccount:argo:argo-workflows\" cannot patch resource \"workflowtasksets/status\" in API group \"argoproj.io\" in the namespace \"argo\""
Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritise the issues with the most 👍.
It's not in the core installation intentionally but in the quickstart manifests, e.g. https://github.com/argoproj/argo-workflows/blob/master/manifests/quick-start-mysql.yaml
See https://github.com/argoproj/argo-workflows/blob/master/manifests/quick-start/base/agent-role.yaml
Intentionally because? At a minimum the documentation should explicitly highlight this. The quickstarts all use latest
tags so are at best unreliable and a bad introduction for newcomers.
cc @alexec who added this in https://github.com/argoproj/argo-workflows/pull/7999
The idea is to have clear permissions for the additional features and avoid excessive permissions on workflows.
Certainly at this point in time, with the information I have at hand as an end user, I think it has made the permissions less clear than they could be.
@terrytangyuan is correct. We don't want to over-permission roles. Users using HTTP templates will need to install additional roles to do so.
I still disagree that closing this is the right course of action. If you want to engage users, you need to tell them this stuff in the documentation. I spend a lot of my time giving free help on Slack, and I could spend a lot less time if the documentation covered this stuff.
I don't know if my installation is bad but I have exactly the same problems with the http template. I don't understand why it doesn't work. I have no error and the HTTP templates do not work. It is true that the documentation on this subject is poor....
@tim-sendible his is a good point. We have spent time trying to update and improve the docs. I don’t have bandwidth now to do this. Would you be interested?
Maybe in a few weeks, yes. Need to get some projects out the door first. So I think we're agreeing this is a valid issue that shouldn't be closed then.
As a new comer to Argo, for what it's worth, I agree with @tim-sendible . I'm finding it terribly confusing to get to grips with Argo due to the documentation not behaving as described. I currently have no idea how to use the HTTP templates after encountering what I believe to be permissions issues and have spent most of the day searching the internet and slack groups to try and figure out what I need to do. None of this is clear in the documentation. I understand that you may not want to over permission roles, however for new comers who want to start building and understanding Argo, layering on security complexity makes it difficult to learn the framework. Why not explicitly tell the user that X Quickstart is not secure? It's the point of a Quickstart to be minimal?
@shbfy would you like to have a go at updating the docs with the information you think is missing?
I think the problem here @alexec is nobody other than the original devs know the purpose of the quiskstart manifests, so making changes to the documentation is prohibitively difficult.
"Quick start" obviously implies some sort of manifest to get up and running fast. But these manifests all default to the "latest" images so are completely unreliable (scroll up in the slack channel for 5 minutes and you'll see just how big an issue this is). So ultimately these seem to be manifests with no actual intention of working...
This makes it tricky to add warning labels and the like when the only reliably working manifest is the officially released "full production" one.
Edit: oh good. I commented using the wrong account. :(
@shbfy would you like to have a go at updating the docs with the information you think is missing?
Yes of course I’m happy to once I’ve got it working.