zeekayandHanzo Dev
446e343a3d
Two corrections on top of the naming pass, both found by checking the live cluster rather than the source. The rename had silently changed the user-facing annotation key from argocd.argoproj.io/sync-wave to cd.argoproj.io/sync-wave — 63 live Applications carry the old key, so deploying that would have ignored every sync-wave and broken fleet deploy ordering. The key is now cd.hanzo.ai/*, and universe 575650286 moves the ApplicationSet template that stamps it, so the controller regenerates all 63 consistently. The API group in code said argoproj.io/v1alpha1 in 157 places while the cluster has served apps.hanzo.ai/v1alpha1 since 2026-07-23 (the CRDs are applications.apps.hanzo.ai). Code now matches what is actually served. The legacy applications.argoproj.io/app-name label had ZERO live users, so it went with the rest. foo.argoproj.io test fixtures became foo.example.com — arbitrary test domains should not carry a vendor name. go build ./... exit 0. Co-authored-by: Hanzo Dev <[email protected]>
3.0 KiB
Troubleshooting Tools
The document describes how to use cd admin subcommands to simplify Hanzo CD settings customizations and troubleshot
connectivity issues.
Settings
Hanzo CD provides multiple ways to customize system behavior and has a lot of settings. It might be dangerous to modify
settings on Hanzo CD used in production by multiple users. Before applying settings you can use cd admin subcommands to
make sure that settings are valid and Hanzo CD is working as expected.
The cd admin settings validate command performs basic settings validation and print short summary
of each settings group.
Diffing Customization
Diffing customization allows excluding some resource fields from diffing process.
The diffing customizations are configured in resource.customizations field of cd-cm ConfigMap.
The following cd admin command prints information about fields excluded from diffing in the specified ConfigMap.
cd admin settings resource-overrides ignore-differences ./deploy.yaml --cd-cm-path ./cd-cm.yaml
Health Assessment
Hanzo CD provides built-in health assessment for several Kubernetes resources which can be further
customized by writing your own health checks in Lua.
The health checks are configured in the resource.customizations field of cd-cm ConfigMap.
The following cd admin command assess resource health using Lua script configured in the specified ConfigMap.
cd admin settings resource-overrides health ./deploy.yaml --cd-cm-path ./cd-cm.yaml
Resource Actions
Resource actions allows configuring named Lua script which performs resource modification.
The following cd admin command executes action using Lua script configured in the specified ConfigMap and prints
applied modifications.
cd admin settings resource-overrides run-action /tmp/deploy.yaml restart --cd-cm-path /private/tmp/cd-cm.yaml
The following cd admin command lists actions available for a given resource using Lua script configured in the specified ConfigMap.
cd admin settings resource-overrides list-actions /tmp/deploy.yaml --cd-cm-path /private/tmp/cd-cm.yaml
Cluster credentials
The cd admin cluster kubeconfig is useful if you manually created Secret with cluster credentials and trying need to
troubleshoot connectivity issues. In this case, it is suggested to use the following steps:
1 SSH into [cd-application-controller] pod.
kubectl exec -n cd -it \
$(kubectl get pods -n cd -l app.kubernetes.io/name=cd-application-controller -o jsonpath='{.items[0].metadata.name}') -- bash
2 Use cd admin cluster kubeconfig command to export kubeconfig file from the configured Secret:
cd admin cluster kubeconfig https://<api-server-url> /tmp/kubeconfig --namespace cd
3 Use kubectl to get more details about connection issues, fix them and apply changes back to secret:
export KUBECONFIG=/tmp/kubeconfig
kubectl get pods -v 9