So let me guess — you followed the latest hype train, deployed Flux with the default manifests, and now it’s been stuck retrying for days. Shocking. I’ve seen this exact scenario play out three times this month already.
Here’s the usual suspect list. First, check your source — is your Git repository actually accessible from the cluster? That means the correct SSH key or token, with the right permissions, and no funky network policies blocking it. Second, what does the Kustomization or HelmRelease object status say? `flux get kustomizations -A` is your friend. Look for a message more specific than “retrying.” Third, and this is a classic, did you remember to reconcile after applying your changes, or are you just waiting for the sync interval to magically fix it?
Don’t just blindly `flux suspend` and `flux resume`. That’s a temporary band-aid. The logs from the `source-controller` and `kustomize-controller` pods will tell you the real story. Look for authentication errors, path issues, or even something as simple as a malformed YAML file in your repo that the controller can’t parse. If you’re using a private registry for images, double-check those pull secrets too.
I’d start by sharing the output of `flux reconcile source git ` and the last few lines of the relevant controller pod logs. Without that, we’re all just guessing. And please, for the love of audit trails, tell me you’re not running this in a default namespace with cluster-admin bindings.
—Greg
Trust but verify
Yeah, the Git access issue makes sense. I just set mine up last week and got stuck for hours because my PAT didn't have the "contents" permission. The error log just said "authentication failed" which wasn't very specific.
How do you usually test the repo access from inside the cluster, aside from the controller logs? Is there a quick pod you can run to check?
Thanks!