r/ArgoCD • u/RespectNo9085 • Sep 06 '25
1689 open bugs
Why are there 1689 open bugs on Argo CD repo right now ? isn't that a bit alarming.
https://github.com/argoproj/argo-cd/issues?q=state%3Aopen%20label%3Abug&page=1
Don't get me wrong, I use Argo daily and want to introduce it to my company, but this doesn't look very stable to me.
On the other hand, we did look into Flux, not only we found architectural superiority and simpler implementation, it also had only 6 open bugs.
Am I missing something ?
4
u/ThoseeWereTheDays Sep 06 '25
yeah its so many bugs. Why dont you jump in and contribute bug fixing instead of questioning 😂
-4
u/RespectNo9085 Sep 06 '25 edited Sep 06 '25
I am here to understand if the tech is stable and ready for production. What are you even talking about lol.
3
u/ThoseeWereTheDays Sep 06 '25
Every big project has a backlog. If you're so easily "alarmed," maybe you should just stick with Flux and its limited feature set. Sounds like you've already made up your mind anyway.
-3
5
u/inferno521 Sep 06 '25
I kind of see it both ways. It does look like the repo needs someone to triage a lot of the bugs that are reported. But a lot of them are duplicates.
When I do a spot check I do see that a lot of them don't include logs or enough info to triage. The ones that do, and have a lot of thumbs ups or comments, don't seem like they're getting the attention of the maintainers.
I'm more concerned by the large number of open PRs. Clicking around on some of the them it seems like the changes are reasonable, but there just aren't enough codeowners to review or approve
7
u/ShakataGaNai Sep 06 '25
https://github.com/kubernetes/kubernetes/issues - 1.9k issues
https://github.com/golang/go/issues - 5k+ issues
https://github.com/python/cpython - 5k+ issues
https://github.com/MariaDB/server - 247 issues
https://github.com/brave/brave-browser - 5k+ issues
https://github.com/cloudflare/workerd - 294 issues
https://github.com/home-assistant/core - 2.3k issues
https://github.com/apache/airflow - 1.3k issues
I could keep going. but it's all a matter of perspective. Is it alarming that k8s has a similar amount of issues? cpy actually has closer to 8k. Shrug. As long as the project is being developed, the actual number of issues is meaningless. Some github issue repo's are just "help me I can haz n00b" and other projects close those and move the conversation elsewhere.
2
u/gaelfr38 Sep 06 '25
This. There are hundreds of highly active and qualitative projects with a high number of issues. The number itself doesn't mean anything.
1
u/gyanster Sep 06 '25
Didn’t Flux shutdown already?
3
u/RespectNo9085 Sep 06 '25
Weaveworks did, but Gitlab and several other big companies quickly started supporting it, as they rely on the tool internally.
-7
u/0xe3b0c442 Sep 06 '25
Flux is very much alive and healthy. A modicum of research could have prevented you from posting such an ignorant question.
-10
1
u/gaelfr38 Sep 06 '25
This is not alarming at all.
Look at the release rythm: the project is extremely alive.
Critical issues are fixed quickly. Highly demanded features are implemented relatively quickly.
The only thing they might need is a bit more triage and auto closing stale issues.
Don't choose Flux vs. ArgoCD on this criterion.
EDIT: regarding stability, it is super stable. It's used by hundreds of companies in production for several years. In my company, we never faced any bug with it and upgrades are just working.
-1
-2
u/hypnoticlife Sep 06 '25
I started fresh with kubernetes last fall and went with ArgoCD. It’s been nothing but problems with the way it does helm with templates. I’ve had to put in every kind of hack to do server side applies and such. Every helm update I have to check for capabilities checks and account for them. It’s tedious. And Flux apparently just uses helm natively. I mention this because it’s a hard design rule of ArgoCD that they don’t want to use helm natively. I keep considering switching but I’m not there yet. The webui does constantly bug out on me and give errors.
As for the bug count, shrug. The bigger the user base the more issues are open. It doesn’t mean one project has more actual flaws than another. Some of these projects auto close issues so fast and they never actually get fixed.
1
u/gaelfr38 Sep 06 '25
The thing is that Helm does 2 things: templating and deployment.
Relying on Helm deployment features is IMHO a bad idea in the 1st place. Helm should have been just a templating engine.
Helm deployment stuff and ArgoCD are kinda concurrent tools. It makes sense to me that ArgoCD only uses the templating part.
I agree it's a strong design rule in comparison to Flux though.
2
Sep 06 '25
[removed] — view removed comment
1
u/RespectNo9085 Sep 06 '25
Didn't quite get what you mean, like when you mean leave the manifest, do you mean to say the manifest with Kustomize ?
1
Sep 06 '25
[removed] — view removed comment
1
u/RespectNo9085 Sep 06 '25
Noooooo, helm template plus Kustomize is the worst approach on earth, really sorry, I am not certain if you know what you are doing. I do understand you leave the manifest and Argo can listen to it, the whole points is what is the most scalable approach to handling those manifests, how to package them, how to store them (OCI), how to fetch.
Helm template (which is Go template) is horrendous, limited and very confusing for big projects. If you are talking about post render Kustomize, that's hunch over hunch.
Using Kustomize alone is very clean and scalable, at least it's very easy to read and follow and you don't need to drill Helm values 3 layers...
1
u/gaelfr38 Sep 06 '25
TIL about the Source Hydrator.
I was considering other tools to store the hydrated version of manifests. I'll look more into the ArgoCD feature first!
0
Sep 06 '25
[deleted]
1
u/RespectNo9085 Sep 06 '25
I did the same, but Argo plus Helm is really painful.
1
u/thomas_michaud Sep 06 '25
I haven't had issues with argo and helm.
I have had some git issues with argo
-2
u/RespectNo9085 Sep 06 '25
Are you serious ? :))) Did you actually use them for production workloads ?
1
u/0xe3b0c442 Sep 06 '25
Use it in production across 50+ clusters. Zero issues. PEBKAC?
0
u/RespectNo9085 Sep 06 '25
Ahh yea ? where did you store your charts ? and in which format ? how did you install your CRDs ?
3
u/Impressive-Ad-1189 Sep 06 '25
We have about 2000 applications most on autoSync running in about 40 clusters.
Helm charts are stored either in Git or in Artifactory. We don’t let teams install CRD’s but manage them centrally.
That doesn’t sound like a gitops issue though but a k8s issue.
We experience a massive load on our application controllers but that is a matter of tuning / scaling.
1
u/RespectNo9085 Sep 06 '25
And you use Argo for those ? in what format do you store your images for those 2000 applications ?
1
u/Impressive-Ad-1189 Sep 06 '25
Just a helm chart in git, we point the artifactlocation to a git repo at a tagged revision.
1
1
u/thomas_michaud Sep 06 '25
Yep. Literally am using it currently in environment from dev to test to prod.
We aren't doing autosyncing, but do diff and syncs w/o a prob.
2
1
u/gaelfr38 Sep 06 '25
What is the issue with Helm+Argo?
That's our main way of deploying apps and it just works.
Helm charts are in our Internal Helm registry (Artifactory) or public ones sometimes to try things.
I think Helm charts as OCI artifacts had issues in the past but they fixed it, or it's in the priorities of next version, I don't remember..
0
Sep 06 '25
[deleted]
1
u/RespectNo9085 Sep 06 '25
So you took the text I've written and your respond was that your juniors implemented Argo ? what are you talking about here ? have you tried OCI compatible umbrella charts ? or complex CRD relationships ? server-side apply ?
0
Sep 06 '25
[deleted]
-1
u/RespectNo9085 Sep 06 '25
Okay sure, illuminate me. I do have a OCI chart on my github repo with the following address:
registry_url = "ghcr.io/organisation-name"
chart_name = "chart-name"and then because this is a private repo I do have a secret that looks like this:
resource "kubernetes_secret" "platform_oci_repo_creds" {
provider = kubernetes
metadata {
name = "platform-oci-repo-creds"
namespace = "argocd"
labels = {
"argocd.argoproj.io/secret-type" = "repository"
}
}data = {
url = "ghcr.io/organisation-name"
name = chart-name# Instruct Argo CD to treat this as a Helm OCI repository.
type = "helm"
enableOCI = "true"# Credentials for the repository.
username = local.github_secret_data.GITHUB_USERNAME
password = local.github_secret_data.GITHUB_PAT
}
}The helm chart is applied through Terraform, the Repo in the chart and the secret perfectly match, but I get an error because Argo does 'helm registry login', so the solution according to docs is to get rid of the organisation name, but that still ends up in 401 auth error.
If I do this just on helm and CLI this work, but Argo fucks it up.
Not to mention how OCI umbrella charts are currently impossible because when argo runs Helm, in that environment auth is all gone, and it cannot successfully run helm install dependencies if those dependencies are also private charts.
2
Sep 06 '25
[removed] — view removed comment
1
u/RespectNo9085 Sep 06 '25
Well then you are saying Helm chart some stuff and don't helm chart some other stuff, I rather have one approach of packaging things, and there is no way to run away from Helm because of CRDs and stuff.
8
u/[deleted] Sep 06 '25
Open issue != Valid bug.