argo-workflows/quick-start/

[giscus[bot]]

argo-workflows/quick-start/

https://argoproj.github.io/argo-workflows/quick-start/

[VladoPortos]

Guys, you can't just end with This will serve the UI on https://localhost:2746 because the moment you open the UI you get hit with log in page. How to log in ? Deploying from helm chart, I can see a secret created called,
argo-workflow-argo-workflows-server-token-jvvnj is that a token it needs ?

[jrbe228]

I had this error when using --auth-mode=server: "Request has been terminated Possible causes: the network is offline, Origin is not allowed by Access-Control-Allow-Origin, the page is being unloaded, etc."

It was fixed by adding the following flag:

argo -n argo server --access-control-allow-origin=* --auth-mode=server

[mwoodpatrick]

I hit this issue and it fixed the issue for me also. I tried using this in the command line suggested in the getting started:

kubectl patch deployment  argo-server  --namespace ${ARGO_NS} --type='json' -p='[{"op": "replace", "path": "/spec/template/spec/containers/0/args", "value": [ "server", "--auth-mode=server", "--access-control-allow-origin=*" ]}]'

Sometimes it appears to work and sometimes when I access the UI I get:

"Request has been terminated Possible causes: the network is offline, Origin is not allowed by Access-Control-Allow-Origin, the page is being unloaded, etc."

[worldsayshi]

I'm using argo-workflows:0.41.2 from https://argoproj.github.io/argo-helm. When trying argo server --auth-mode=server I get configmaps "workflow-controller-configmap" not found. There is one configmap called argo-workflows-workflow-controller-configmap. Seems the helm chart is prepending the releaseName to the configmap and the argo cli doesn't expect that.

I could remedy that by running:

argo -n argo server --access-control-allow-origin=* --auth-mode=server --configmap argo-workflows-workflow-controller-configmap

I can now get into the GUI at https://localhost:2746

[agilgur5]

@worldsayshi the quick-start is meant to be run via the quick-start manifests, as it says on this very page.

So that makes sense that if you install via argo-helm, your config will differ, as you didn't follow the installation directions.

[worldsayshi]

I see. I thought the installation manifest was the same. I switched to the helm chart to try to find a way to get past the login screen. I guess with the quick start manifest i wouldn't have had that issue to begin with..

[yaoxinwang-git]

If you want to try out Argo Workflows and don't want to set up a Kubernetes cluster, the community is working on a replacement for the old Katacoda course since Katacoda was shut down. Please give a thumbs up or comment on this issue with your support and feedback.

[terrytangyuan]

Which issue are you referring to? This is a discussion thread for quick start guide.

[rish8089dunzo]

@yaoxinwang-git
where can I find replacement for the old Katacoda course?

[tico24]

@rish8089dunzo It doesn't exist yet. We are hoping to have something out in the next week or so.

[caelan-io]

@rish8089dunzo @yaoxinwang-git Hello, You can find the new course here on Killercoda, a Katacoda replacement: https://killercoda.com/pipekit/course/argo-workflows

@tico24 and I have posted a new version of the Intro to Argo Workflows course, compatible with v3.4.2. We're looking for more user feedback before improving on and adding to the new course.

For more info, see issue #8899

[yaoxinwang-git]

when i want to use UI, I curl service argo-server clusterIP:port ,tell me Empty reply from server, please tell how to visit UI

[yaoxinwang-git]

edit service type nodeport then use https://ip:nodeport to visit ui

[oschrenk]

I strongly discourage from using the manifest mentioned in the beginning of the document. It doesn't work. You are better off using a quickstart manifest attached to a release eg

kubectl apply -n argo -f https://github.com/argoproj/argo-workflows/releases/download/v3.3.9/quick-start-postgres.yaml

I ran into

W0810 13:54:18.440110       1 reflector.go:324] pkg/mod/k8s.io/client-go@v0.24.3/tools/cache/reflector.go:167: failed to list *v1alpha1.WorkflowArtifactGCTask: the server could not find the requested resource (get workflowartifactgctasks.argoproj.io)

where artifacts didn't work. See also https://cloud-native.slack.com/archives/C01QW9QSSSK/p1660203791944519

Others ran into issues with the cron flows.

[tim-sendible]

I have modified this page to point users to the correct manifests now.

[RiyajKazieomccain]

Hi Team,

I have deployed the argo-workflow using helm, whenever i try to submit the workflow getting below error. Does anyone know the solution for the same.

Forbidden: workflows.argoproj.io is forbidden: User "system:serviceaccount:argo-workflows:default" cannot create resource "workflows" in API group "argoproj.io" in the namespace "default"

[Souheil-Yazji]

Check the ClusterRoleBinding mentioned in the error and associated Cluster role for the service account "argo-workflows". Make sure that it has "CREATE" permissions for the "workflows" resource in API group "argoproj.io".

Check out https://github.com/argoproj/argo-helm/tree/main/charts/argo-workflows#pre-requisites which might address your issue.

[zhouduo0]

how to create argo namespace

[Souheil-Yazji]

kubectl create namespace argo is provided in the docs above

[Alig1493]

Shouldn't the port forwarding be done for the service instead of the deployments?

[tico24]

From a technical standpoint it doesn't matter. PFing a service just ends up pointing at the pod anyway. From an ease of use perspective, it might be a little easier I guess as the name doesn't change. However, in this case we PF the deployment anyway, which works around the name-change issue.

PRs are welcome.

[Hanliber]

Every time I submit the same workflow，argo always create some new pods to run this workflow, are there some other ways to reuse the pods which this workflow used to create?

[fsedano]

The idea is each workflow starts from a clean and well known state, so pod reuse does not look the right thing to do. Can you elaborate on the use case for this?

[Hanliber]

Can I define each task in the workflow as a type of deployment? In this way, every time the workflow is run, each pod will not be in the completed state.