Hello,

I am creating a repo using a similar approach to this one but using helm instead of kustomize. I have a couple questions regarding the setup that I couldn't find explanations in the docs:

1. When you guys bootstrap it in a cluster for the first time I'm guessing the steps are more or less:

• Create the k8s cluster
• Install argocd (manually or with a script)
• Run kubectl apply -n my-argo-namespace -k argoproj-deployments/argoproj or e.g. kustomize build https://github.com/argoproj/argoproj-deployments/tree/master/argoproj/

2. I was wondering why is kustomize the suggested tool to manage argo with argo. Do you have any specific pointers or recommendations if I were to do it with helm instead?

Some resources are still hosted in the old GCP account and need to be migrated, a non-exhaustive list is:

• blog.argoproj.io
• https://github.com/argoproj/argo-site
• https://github.com/argoproj/rollouts-demo

The list of permission to the GCP account is managed as code, but the users access is given on personal gmail accounts. Some users might not want to have their personal gmail in the source code publicly available.
A Terraform Data Source can be used to retrieve the list of user gmail to use for permissions.

AC

• Use a low-cost data source to store the list of gmails.
  • Could be managed by a github team, and have a data source that contains the mapping of github username <-> gmail account.
• Update documentation on how to add/remove a user
• Update CODEOWNERS based on the github team / users

Some secrets used for different applications have been created manually in the cluster.
Using SealedSecrets seems like the best approach to manage them as code.

Another alternative would be External Secrets, but it would require a provider such as GCP Secret Manager at additional costs and secrets at this location would still need to be managed manually.

The list of the secrets that were applied manually are:

• dex/dex
• argocd/argocd-auth
• prometheus-operator/prometheus-operator-grafana
  • Only the key admin-password
• argo/argo-server-sso
• argo/argo-workflows-webhook-clients

AC

• Update the different README.md to reflect the changes
• Manage secrets as code

It looks like an example was copied and customized, but the README is still verbatim from the example which is rather confusing when looking through this repo.

This matters since this repo is linked from the user guide as an example for how to do ArgoCD on ArgoCD.

Here is the error we are encountering:

error: add operation does not apply: doc is missing path: "/spec/template/spec/containers/0/command/-": missing value

Proposed fix:
#19

Steps:

• Clone project
• Change domain
• Apply deployment
  Result: invalid certificate.
  The logs of certificate-manager: 1 sync.go:50] cert-manager/controller/ingress-shim "level"=0 "msg"="not syncing ingress resource as it does not contain a "cert-manager.io/issuer" or "cert-manager.io/cluster-issu
  er" annotation" "resource_kind"="Ingress" "resource_name"="http01" "resource_namespace"="argocd"
  I guest the problem come from version of certificate-manager. Please help me.

The domain argoproj.io is currently managed by the CNCF, but the nameserver must be updated to use a new DNS zone in the current project. All records needs to be migrated.

AC

• DNS managed in Infra as code
• DNS migrated
• Old DNS decomissioned

It seems the App of Apps is better implemented by using ApplicationSets , do you have any plans of updating the code to use this or is there a specific reason someone should not use it ?

The Github team currently used in ArgoCD and Argo Workflow auth does not exist. It is impossible to login as an admin to both tools.

AC

• Create 2 new admin teams for Workflow and ArgoCD
• Update both tools RBAC configurations

It is obvious that the argocd-secret object isn't being managed here.

This has been an annoying part of trying to manage all of ArgoCD from a kustomize application as recommended in the docs.

Can you add documentation explaining where and how argocd-secret is begin managed?

All argo applications under argoproj/ folder are applied manually. Having a new application to automatically sync the applications would reduce burden on people with cluster access to update the applications manually and provide a better experience when contributors merge a pull request.

AC

• Create apps-of-apps in argoproj folder that syncs itself and other apps.

The Argoproj Workflows deployment is returning a 503. I first encountered this issue last week and saw it again today so I'm raising an issue. It is unclear when it actually became unavailable, but this was the last commit to Workflows and I have to imagine its been up since Jan 6th.

For some reason the logs are not viewable in the ArgoCD UI on 2.4.0-385dec96