jessesuen

Lead and core contributor to Argoproj here.

I agree that Tekton and Argo Workflows share a closer comparison than with Argo CD (despite the "CD" acronym appearing in the name Tekton CD). Workflows is aimed to be a more general purpose workflow engine. I like to explain workflows as a fancy Kubernetes Job object, which can be used as a building block to higher level applications.

I believe the majority of workflow users are using workflows for ML, ETL, data processing pipelines. Its strength is being able to leverage your kubernetes cluster as an auto-scaling compute grid, with highly advanced scheduling capabilities (i.e. scheduling based on node attributes, pod priorities, resource requirements, etc...). That said, a fair share of users are using workflows as a lightweight CI solution, though it requires work to glue in other components to provide the complete solution (e.g. Argo Events to handle git webhooks)

Thanks. We've updated the docs to outline the bare minimum set of privileges.

Docs have been updated and linked to in the getting started guide: https://github.com/argoproj/argo/blob/master/docs/workflow-r...

Thank you. We didn't submit the post, but we actually have https://argoproj.io which redirects to the argoproj.github.io page. Actually we've been meaning to take advantage of GitHub's custom domain so we can drop the github.io entirely.

I always explain that Workflows should be thought of as a fancier version of Kubernetes Jobs. Some of the killer features, IMO, are with artifact management and control flow (e.g. loops, conditionals, parallelism).

So far, our most common use case has been in the machine learning space. One of the biggest problems it can solve is the ability to leverage a Kubernetes cluster as an auto-scaling compute grid for all forms batch processing. We've been working closely with ML teams at various companies, both large and small, and many of our features were implemented to address the ML use cases (e.g. DAG support, loops/step expansion, step aggregation).

With that said, Argo got its start trying to address the CI use case, so we also feel like we handle that one pretty well.

The workflow controller has always been intended to be a lego block to enable higher level applications to be built on top of it.

I work on Argo. Those instructions are mainly for demo purposes because many of the examples need admin privileges. The amount of access which is needed, is really dependent on what your workflow is doing (e.g. if your workflow needs to deploy a resource, then you need to give the service account 'create' privileges on that resource). Currently, the bare minimum for a workflow to function is outlined here:

https://github.com/argoproj/argo/issues/983#issuecomment-435...

I will make sure that the docs are updated, so that this information is well understood.

I work on argo. The workflow-controller is very tolerant to crashes and designed to be this way. Workflow state is captured in the workflow CRD object (in k8s etcd). Because step names are formulated, in the event of a crash (say before the created pod is persisted in etcd), when the controller restarts and tries to schedule the pod again, it hits an AlreadyExists error and understands how to handle this. Thus, workflows are idempotent in crash scenarios.