Give Your Feedback on Argo CD!

[reginaelyse]

Since Argo CD v2.0-rc1 was just released, it would be great to get feedback (positive and negative) on Argo CD overall. This feedback can be used to make improvements in later releases and help focus attention and future efforts on the areas where the greatest improvements can be made for users.

In particular, we would appreciate feedback on the Argo CD UI specifically, but all feedback is appreciated!

Please offer whatever feedback you have here in this discussion, or propose other ways to solicit more feedback!

[TiagoJMartins]

I've noticed two things that I'm not able to currently provide examples for but I'm sure can be easily replicated:

• The "Show Orphaned" button on the Application view can sometimes be hard to click. It feels like the clickable div should be bigger.
• The same button won't show up under a certain screen width (e.g. mobile)

And a suggestion:

• A compact global application view (kind of a scaled down version of the default blocks) would be awesome to have.

[paveq]

I'm still on 1.8.x, but I guess this also applies to 2.x: when using RBAC's on argo-cd it's not reflected in the UI in any way (ie. user sees actions/buttons he can't execute).

Ideally all actions, views and buttons user does not have access to should be hidden from the view, not to cause confusion.

[r0bj]

There are many things than can be set via annotation in Application CRD object, e.g.:

• argocd.argoproj.io/sync-options
• argocd.argoproj.io/manifest-generate-paths
• notifications related (notifications.argoproj.io/subscribe.on-sync-succeeded.slack, notifications.argoproj.io/subscribe.on-sync-failed.slack, notifications.argoproj.io/subscribe.on-health-degraded.slack)
• image updater related (argocd-image-updater.argoproj.io/image-list: gcr.io/heptio-images/ks-guestbook-demo:^0.1, argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd-image-updater/git-creds)
  etc.

Why not extend Application CRD to include those options natively?
It would be easier to have dedicated fields in CRD like e.g.:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
spec:
  imageUpdater:
  - name: <image_name>
    updateStrategy: <strategy>
[...]

than use annotations with complex syntax like:

argocd-image-updater.argoproj.io/<image_name>.update-strategy: <strategy>

(if mixing options from different argo subprojects in one CRD is not possible then it maybe be achieved via ref to other CRD object)

Similarly there are many things you can configure via argocd-cm ConfigMap: repositories, users, configManagementPlugins. Why not use separate CRD for those?
Would be definitely more kubernetes way.

[alexmt]

Agree that support via CRD fields is more convenient than annotations.
We are use annotations for components that have not reached v1.0 version and still changing. Argo CD Notifications is a mature now and good candidate to make it into Application CRD.

[mars64]

First of all hugemongous thanks for the amazing work! ArgoCD has completely changed how I think about deployment strategies.

• I love the pod/group-by-node view! I find myself wanting to have this view to observe all pods/nodes alignment, despite the filter. I know this isn't the point of argocd, and it starts to feel a lot like other projects (e.g. kube-ops-view)). But it would sure be neat.
• The RBAC/SSO story is one of the hardest for me to understand. I'd love to see something like a readonly display of the permissions of my current user or group has in the UI at /user-info. This would be super helpful in troubleshooting SSO configurations.
  • a homebrew formulae for argocd-util would be sweet
  • I'm probably reading this wrong, but the validate-a-policy docs say we should be able to run argocd-util against k8s to validate RBAC configs within a live CM -- but everything I've tried (with 2.0.0-rc1) indicates I can't do this. It seems I must run against a --policy-file (which seems to line up with the cli reference docs here)
• I find the content boxes of each object to be too small for the length of our object names. We're making heavy use of appOfApps and multi-cluster management -- so we need to prefix all objects for uniqueness, which causes the names to be so long we have to mouse-over the break-out box to observe the URL to see what we're actually pointing at. Simple solution: bigger and/or more flexible boxes. Not so simple solution: organize objects in their own area, i.e. treat "projects" as their own "namespaces" within argocd such that each object doesn't require a fully unique name? I'm uncertain how applicationSets might change this equation
• Safely defining secrets in a declarative configuration is pretty well impossible right now. Defining SSO client_secret or repository credentials in the argocd-cm in a repository is completely off the table. In terms of live cluster objects -- even having in a secret isn't ideal, I'd rather be able to provide environment variables to ArgoCD server for secrets. We use the BanzaiCloud Vault Webhook, so i'd love to have an env var prepped in the deployment/sts that triggers the webhook to inject at runtime for things like client_secret of SSO connections.

[alexmt]

a homebrew formulae for argocd-util would be sweet

This is the plan. We are going to add argocd-util into existing homebrew. This is cheap since technically argocd and argocd-util is the same binary and we just need to add a symlink.

[alexmt]

I'm probably reading this wrong, but the validate-a-policy docs say we should be able to run argocd-util against k8s to validate RBAC configs within a live CM -- but everything I've tried (with 2.0.0-rc1) indicates I can't do this. It seems I must run against a --policy-file (which seems to line up with the cli reference docs here)

Checked the CLI documentation - indeed it sounds like tool should validate live CM. Could you please create bug report?

/cc @jannfis

[alexmt]

Safely defining secrets in a declarative configuration is pretty well impossible right now. Defining SSO client_secret or repository credentials in the argocd-cm in a repository is completely off the table. In terms of live cluster objects -- even having in a secret isn't ideal, I'd rather be able to provide environment variables to ArgoCD server for secrets. We use the BanzaiCloud Vault Webhook, so i'd love to have an env var prepped in the deployment/sts that triggers the webhook to inject at runtime for things like client_secret of SSO connections.

We are attempting to improve it using argocd-util CLI. The tool now provides commands to generate declarative specs:
argocd-util cluster generate-spec, argocd-util repo generate-spec etc

[MatteoJoliveau]

We've started deploying ArgoCD in a number of different clusters, currently all on 2.0-rc1. This is my opinion so far (tl;dr we love it ❤️ , it just needs a bit of polish):

UI

• The access token expiration requiring a full page refresh is annoying, especially when doing an action because it forces to reclick the button to resubmit the action. Maybe doing a silent refresh a few moments before the token expires would help (that's what we usually do in SPAs with OAuth authentication at least).
• Filtering is a bit cumbersome on smaller viewports (such as a half-screen-width browser tab), but I understand that scaling a complex UI on small screen is not easy
• I don't really like that opening a panel (e.g. resource summary, sync status, app details etc) counts as a hop in the browser's history, because it means that clicking the back button doesn't bring me to the previous page, but it instead closes the panel. And if I manually closed it by clicking on something else, going back in history reopens it. It's really cumbersome to navigate with mouse/browser back buttons because of this behaviour.

CRDs

• Please please please, give us cross-namespace Applications and Projects. Being forced to create them in the same namespace as the ArgoCD controller means developers either need to create them via the UI (which is not very GitOps friendly) or ask a cluster admin, or they need write permissions in the ArgoCD namespace (therefore potentially screwing with other teams' apps). Many other operators and controller can watch multiple namespaces without performance issues. We could use a label-based selector for handling cases where there are multiple instances of Argo in the same cluster, like the Prometheus or Grafana operators do.
• More custom types for configuration instead of configmaps. For example, registering Git/Helm repos as custom resources would allow for dev teams to manage their own repos (creating them in their own namespaces) and auth credentials (via regular kube secrets, so that we can store them in something like Vault and sync them with the cluster) without having to bother a cluster admin for onboarding.
• Probably nit-picking compared to the rest, but I think that SyncOptions could be YAML keys instead of key=value strings. This would help with documentation and discovery (think autocomplete in modern IDEs), at the cost of forward compatibilty with future new options.
• Splitting argocd-secrets into multiple objects so that we can fetch different parts from different sources (e.g. the OIDC client credentials from a secure Vault and the TLS certificates from cert-manager) is no longer an issue, because it will be fixed by feat: allow argocd-cm to reference K8S Secrets (#4188) #4342. So this is not a report, it's a big "thank you"!

Operations

• We often have 100+ applications registered, sometimes in groups of 20 per repository (monorepo-ish projects). The argocd-server and argocd-repo-server deployments scale fine, but we cannot scale the application-controller past one replica since it only shards clusters between multiple instances. We often hit pretty heavy performance issues when syncing apps, and the pod starts consuming a lot of CPU and RAM while doing so. I know it's not doing an easy job, and comparing YAMLs can be pretty resource intensive, but maybe there is a way to shard applications, or at least projects, between replicas? I don't have an implementation suggestion in mind, it could be something that is technically impossible with the current ecosystem and/or the Kube API as it is. But I think it's useful to at least report the problem, because at the moment it's our main bottleneck on large multitenant clusters.

Disclamer

This is based on around 6 months of testing and production experience with ArgoCD in multitenant, single-cluster deployments. Some things listed here may be due to an incorrect usage of a feature on our part, or could be completely wrong and we misunderstood the intended way of using said feature. If a project member would like to point things out and correct me, please do!
We love ArgoCD, it's probably the best deployment tool I have used in quite a while, and it's delivering a fantastic experience. We want it to succeed so that we can succeed with our customers.

Thank you everyone working on this. You're doing a mighty fine work.

[alexmt]

Thank you for the detailed feedback!

I don't really like that opening a panel (e.g. resource summary, sync status, app details etc) counts as a hop in the browser's history, because it means that clicking the back button doesn't bring me to the previous page, but it instead closes the panel. And if I manually closed it by clicking on something else, going back in history reopens it. It's really cumbersome to navigate with mouse/browser back buttons because of this behaviour.

Totally agree, could you please create a bug repo (adding a reminder to fix it anyway).

Please please please, give us cross-namespace Applications and Projects.

I'm guessing this would help in case when Argo CD is managing there same cluster where it is running, correct? So that developers could create apps in the "target" namespaces. We've discussed that use-case recently. One idea was to solve it by adding e.g. ApplicationSource CRD that contains application source only and creates an application CRD (with inferred cluster url and namespace ) in the argocd namespace. This would allow developers self manage Argo CD apps in namespaces that they control. I think this is a perfect candidate for https://github.com/argoproj-labs/ project.

More custom types for configuration instead of configmaps. For example, registering Git/Helm repos as custom resources would allow for dev teams to manage their own repos

As an administrator who has to onboard developers, I totally understand that pain and want to make it self service :) .
So far I was thinking to resolve it by implementing #5283 and #2251 . We also plan to simplify repo configuration (#5436) and leverage argocd-util to generate specs (e.g. argocd-util repo generate-spec)

We often have 100+ applications registered, sometimes in groups of 20 per repository (monorepo-ish projects). The argocd-server and argocd-repo-server deployments scale fine, but we cannot scale the application-controller past one replica since it only shards clusters between multiple instances.

The v2.0 introduced ApplyOutOfSyncOnly=true sync option that reduces number of kubectl apply. It might help with cpu/memory usage during syncing. The sharding of one cluster is possible and we are planning to work on it.

[nicolaracco]

The documentation. I'm using argocd since a couple of weeks and I'm struggling to find answers for the declarative setup. I had to inspect the crds manifests to understand where certain props should have been placed.
Also in the examples, one would expect to find examples for declarative configuration of the example apps too.

[alexmt]

The documentation refresh is one of the next release priorities: #5635
Another effort to simplify declarative config management is the argocd-util CLI. (see The argocd-util CLI for everyday Argo CD Utilities in release blog )

So we totally agree with your feedback and working on improving it.

[abdennour]

In a Big companies where Dev & Ops are huge Silos, ArgoCD helps us to break these silos.
i am the designer and implementer of the whole DevOps platform in the organization.
However, we would like to see an end to end example where CI is Workflows+Events and CD is argocD.
We would like to package these examples in helm charts

[oeN]

First of all, thanks for this awesome tool! (really mean it)

I have a TODO to open an issue about this problem 😛 but I'll spoil it here.
When you sync an application and there is an error on an ExternalSecret the error reported by ArgoCD is misleading.
If an application creates an ExternalSecret and the secret does not exist on the external secret store (i.e. AWS Secrets Manager) the error reported by ArgoCD is about a wrong formatted YAML and you can understand that the error is about the external secret only for its status.

[greg-caffeine]

@reginapizza, we're definitely enjoying the concept of the ArgoCD method of continuous deployment. Performance is definitely our #1 issue, though. ArgoCD is a hard sell to a developer when currently it takes at least 3 minutes before the sync starts and 5-6 minutes for the sync and progression to complete. We have yet to look into our options for performance optimization, but we see high (>75% of one core) CPU utilization on the application-controller at all times. We'd welcome some internal performance improvements or at least a performance tuning guide.

Thanks!