DevFW-CICD/argocd-helm
6
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs(argo-workflows): Fix typos and add missing words in README (#1248)

Browse source 
* Fix typos and add missing words in README.md

No real content changes, just textual improvements.

* Bump version and add changelog

Signed-off-by: Marco Kilchhofer <mkilchhofer@users.noreply.github.com>

* Sync changes README.md -> README.md.gotmpl

Signed-off-by: Marco Kilchhofer <mkilchhofer@users.noreply.github.com>

Co-authored-by: Marco Kilchhofer <mkilchhofer@users.noreply.github.com>
This commit is contained in:
Lieven Govaerts 2022-05-09 21:37:11 +02:00 • committed by GitHub
parent ef70ad9edd
commit b849ee9775
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 12 additions and 12 deletions
Download patch file Download diff file Expand all files Collapse all files

10
charts/argo-workflows/README.md
View file

@ -1,23 +1,23 @@
# 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](https://github.com/kubernetes/helm).
This is a **community maintained** chart. It is used to set up argo and its needed dependencies through one command. This is used in conjunction with [helm](https://github.com/kubernetes/helm).
If you want your deployment of this helm chart to most closely match the [argo CLI](https://github.com/argoproj/argo-workflows), 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.
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 create these.
A few options are:
- Manually create a ServiceAccount in the Namespace which your release will be deployed w/ appropriate bindings to perform this action and set the `serviceAccountName` field in the Workflow spec
- Manually create a ServiceAccount in the Namespace in which your release will be deployed w/ appropriate bindings to perform this action and set the `serviceAccountName` field in the Workflow spec
- Augment the `default` ServiceAccount permissions in the Namespace in which your Release is deployed to have the appropriate permissions
## Usage Notes
### Workflow controller
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.
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 its configuration options to set the `instanceID` of the workflow controller to be properly scoped for your needs.
### Workflow server authentication
@ -217,7 +217,7 @@ Fields to note:
1. switched to quay.io as the default registry for all images
1. removed any included usage of Minio
1. aligned the configuration of serviceAccounts with the argo-cd chart, ie: what used to be `server.createServiceAccount` is now `server.serviceAccount.create`
1. moved the previously known as `telemetryServicePort` inside the `telemetryConfig` as `telemetryConfig.servicePort` - same for `metricsConfig`
1. moved the field previously known as `telemetryServicePort` inside the `telemetryConfig` as `telemetryConfig.servicePort` - same for `metricsConfig`
[affinity]: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/
[links]: https://argoproj.github.io/argo-workflows/links/