argo-helm/charts/argo
Sean Johnson 5f33036890
Fix up chart linting, add docs and lint script (#146)
This updates the Helm linting system with the following changes:

- Import lintconf.yaml with small change to comment distance in order to
match existing values.yaml standards
- Update Chart.yaml and values.yaml in each chart to pass linting
standards
- Maintainers added to each chart from OWNERS + CODEOWNERS, the linter
requires GitHub usernames so argo-events maintainer names were converted
- README updated with documentation around chart standards and testing
- A local shell script added for running lint tests locally
2019-11-06 08:08:17 +11:00
..
charts Updating helm chart and improving style (#7) 2018-06-04 07:39:53 -07:00
templates Fix argo CRD deployment (#140) 2019-10-28 19:45:55 -04:00
.helmignore Create agro helm chart 2018-01-02 16:45:35 -08:00
Chart.yaml Fix up chart linting, add docs and lint script (#146) 2019-11-06 08:08:17 +11:00
README.md Update argo chart for 2.4.2 (#130) 2019-10-22 09:10:13 -07:00
requirements.lock Updating helm chart and improving style (#7) 2018-06-04 07:39:53 -07:00
requirements.yaml Updating helm chart and improving style (#7) 2018-06-04 07:39:53 -07:00
values.yaml [argo] Add workflow persistence configuration (#133) 2019-10-22 15:08:29 -07:00

README.md

Argo Workflows Chart

This is a community maintained chart. It is used to set up argo and it's needed dependencies through one command. This is used in conjunction with helm.

If you want your deployment of this helm chart to most closely match the argo CLI, you should deploy it in the kube-system namespace.

Pre-Requisites

This chart uses an install hook to configure the CRD definition. Installation of CRDs is a somewhat privileged process in itself and in RBAC enabled clusters the default service account for namespaces does not typically have the ability to do create these.

A few options are:

  • Setup the CRD yourself manually and use --set installCRD=false when installing the helm chart. Find the CRDs in the argo codebase
  • Manually create a ServiceAccount in the Namespace which your release will be deployed w/ appropriate bindings to perform this action and set the init.serviceAccount attribute
  • Augment the default ServiceAccount permissions in the Namespace in which your Release is deployed to have the appropriate permissions

Usage Notes:

This chart defaults to setting the controller.instanceID.enabled to false now, which means the deployed controller will act upon any workflow deployed to the cluster. If you would like to limit the behavior and deploy multiple workflow controllers, please use the controller.instanceID.enabled attribute along with one of it's configuration options to set the instanceID of the workflow controller to be properly scoped for your needs.

Values

The values.yaml contains items used to tweak a deployment of this chart. Fields to note:

  • controller.instanceID.enabled: If set to true, the Argo Controller will ONLY monitor Workflow submissions with a --instanceid attribute
  • controller.instanceID.useReleaseName: If set to true then chart set controller instance id to release name
  • controller.instanceID.explicitID: Allows customization of an instance id for the workflow controller to monitor
  • controller.workflowNamespaces: This is a list of namespaces where workflows will be ran
  • minio.install: If this is true, we'll install minio and build out the artifactRepository section in workflow controller config map.
  • artifactRepository.s3.accessKeySecret and artifactRepository.s3.secretKeySecret These by default link to minio default credentials stored in the secret deployed by the minio chart.