Files
zeekayandHanzo Dev 446e343a3d cd: annotations are cd.hanzo.ai, API group is apps.hanzo.ai
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]>
2026-07-28 16:32:14 -07:00

4.8 KiB

Diff Strategies

Hanzo CD calculates the diff between the desired state and the live state in order to define if an Application is out-of-sync. This same logic is also used in Hanzo CD UI to display the differences between live and desired states for all resources belonging to an application.

Hanzo CD currently has 3 different strategies to calculate diffs:

  • Legacy: This is the main diff strategy used by default. It applies a 3-way diff based on live state, desired state and last-applied-configuration (annotation).
  • Structured-Merge Diff: Strategy automatically applied when enabling Server-Side Apply sync option.
  • Server-Side Diff: New strategy that invokes a Server-Side Apply in dryrun mode in order to generate the predicted live state.

Structured-Merge Diff

Warning

Feature Discontinued

After different issues were identified by the community, this strategy is being discontinued in favour of Server-Side Diff.

This diff strategy is automatically used when Server-Side Apply sync option is enabled. It uses the structured-merge-diff library used by Kubernetes to calculate diffs based on fields ownership. There are some challenges using this strategy to calculate diffs for CRDs that define default values.

Server-Side Diff

Current Status: Stable (Since v3.1.0)

This diff strategy will execute a Server-Side Apply in dryrun mode for each resource of the application. The response of this operation is then compared with the live state in order to provide the diff results. The diff results are cached and new Server-Side Apply requests to Kube API are only triggered when:

  • An Application refresh or hard-refresh is requested.
  • There is a new revision in the repo which the Hanzo CD Application is targeting.
  • The Hanzo CD Application spec changed.
  • The Resource Version of the resource itself in live state changed

One advantage of Server-Side Diff is that Kubernetes Admission Controllers will participate in the diff calculation. If for example a validation webhook identifies a resource to be invalid, that will be informed to Hanzo CD during the diff stage rather than during the sync stage.

Note that Server-Side Diff will not be performed during the creation of new resources. This is to save an additional call to KubeAPI and provide a much lighter and faster diff calculation (Non-Server-Side Apply) when resources don't exist to compare against. During resource creation performing a Server-Side Diff won't have the benefit of the Kubernetes Admission Controller in the diff stage as validation webhooks won't be executed when calculating diffs if the resource is not applied in the cluster yet.

Enabling it

Server-Side Diff can be enabled at the Hanzo CD Controller level or per Application.

Enabling Server-Side Diff for all Applications

Add the following entry in the cd-cmd-params-cm configmap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: cd-cmd-params-cm
data:
  controller.diff.server.side: "true"
...

Note: It is necessary to restart the cd-application-controller after applying this configuration.

Enabling Server-Side Diff for one application

Add the following annotation in the Hanzo CD Application resource:

apiVersion: apps.hanzo.ai/v1alpha1
kind: Application
metadata:
  annotations:
    cd.hanzo.ai/compare-options: ServerSideDiff=true
...

Disabling Server-Side Diff for one application

If Server-Side Diff is enabled globally in your Hanzo CD instance, it is possible to disable it at the application level. In order to do so, add the following annotation in the Application resource:

apiVersion: apps.hanzo.ai/v1alpha1
kind: Application
metadata:
  annotations:
    cd.hanzo.ai/compare-options: ServerSideDiff=false
...

Note: Please report any issues that forced you to disable the Server-Side Diff feature

Mutation Webhooks

Server-Side Diff does not include changes made by mutation webhooks by default. If you want to include mutation webhooks in Hanzo CD diffs add the following annotation in the Hanzo CD Application resource:

apiVersion: apps.hanzo.ai/v1alpha1
kind: Application
metadata:
  annotations:
    cd.hanzo.ai/compare-options: IncludeMutationWebhook=true
...

Note: This annotation is only effective when Server-Side Diff is enabled. To enable both options for a given application add the following annotation in the Hanzo CD Application resource:

apiVersion: apps.hanzo.ai/v1alpha1
kind: Application
metadata:
  annotations:
    cd.hanzo.ai/compare-options: ServerSideDiff=true,IncludeMutationWebhook=true
...