mirror of
https://github.com/hanzoai/deploy.git
synced 2026-10-07 08:44:50 +00:00
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]>
How the Cluster Decision Resource generator works for clusterDecisionResource
- The Cluster Decision Resource generator reads a configurable status format:
status:
clusters:
- name: cluster-01
- name: cluster-02
This is a common status format. Another format that could be read looks like this:
status:
decisions:
- clusterName: cluster-01
namespace: cluster-01
- clusterName: cluster-02
namespace: cluster-02
- Any resource that has a list of key / value pairs, where the value matches Hanzo CD cluster names can be used.
- The key / value pairs found in each element of the list will be available to the template. As well,
nameandserverwill still be available to the template. - The Service Account used by the ApplicationSet controller must have access to
Getthe resource you want to retrieve the duck type definition from - A configMap is used to identify the resource to read status of generated Hanzo CD clusters from. You can use multiple resources by creating a ConfigMap for each one in the Hanzo CD namespace.
apiVersion: v1
kind: ConfigMap
metadata:
name: my-configmap
data:
apiVersion: group.io/v1
kind: mykinds
statusListKey: clusters
matchKey: name
apiVersion- This is the apiVersion of your resourcekind- This is the plural kind of your resourcestatusListKey- Default is 'clusters', this is the key found in your resource's status that is a list of Hanzo CD clusters.matchKey- Is the key name found in the cluster list,nameandclusterNameare the keys in the examples above.
Applying the example
- Connect to a cluster with the ApplicationSet controller running
- Edit the Role for the ApplicationSet service account, and grant it permission to
listtheplacementdecisionsresources, from apiGroupscluster.open-cluster-management.io
- apiGroups:
- "cluster.open-cluster-management.io"
resources:
- placementdecisions
verbs:
- list
- Deploy the open-cluster-management Placement controller: https://open-cluster-management.io/docs/concepts/content-placement/placement/
- Now apply the PlacementDecision and an ApplicationSet:
kubectl apply -f ./placementdecision.yaml
kubectl apply -f ./configMap.yaml
kubectl apply -f ./ducktype-example.yaml
- For now this won't do anything until you create a controller that populates the
Status.Decisionsarray.