mirror of https://github.com/hanzoai/deploy.git synced 2026-10-07 08:44:50 +00:00

Files

T

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

3.6 KiB

Raw Permalink Blame History

v3.5 to 3.6

Breaking Changes

Repo-server OTLP headers environment variable renamed

The repo-server now reads OpenTelemetry collector headers from CD_REPO_SERVER_OTLP_HEADERS instead of the inconsistently-named CD_REPO_OTLP_HEADERS. The new name follows the CD_<COMPONENT>_OTLP_HEADERS convention used by every other Hanzo CD component (e.g. CD_SERVER_OTLP_HEADERS, CD_APPLICATION_CONTROLLER_OTLP_HEADERS) and matches the name the shipped repo-server Deployment already injects from the otlp.headers config map key.

Impact:

The default manifests already set CD_REPO_SERVER_OTLP_HEADERS, so most operators are unaffected.
If you set CD_REPO_OTLP_HEADERS directly (for example via a custom Deployment patch or Helm values), rename it to CD_REPO_SERVER_OTLP_HEADERS. The old variable is no longer read.

Behavioral Improvements / Fixes

Health transition events now identify the causing resource(s)

The Updated health status event emitted when an Application's aggregated health changes now includes the resource(s) that caused the new status.

New behavior:

The event message gains a (Caused by ...) suffix listing the offending resource(s), for example:

Updated health status: Healthy -> Degraded (Caused by apps/Deployment:default/api)

Up to three resources are listed. This makes it easier to investigate flapping application health by pointing directly at the resource(s) driving the change.

Impact:

If you consume this event message and parse it programmatically, update your parser to tolerate the new (Caused by ...) suffix.

Tracing sampler is now parent-based and configurable

Previously, when OpenTelemetry tracing was enabled (--otlp-address set), Hanzo CD sampled every span unconditionally (AlwaysSample). Hanzo CD now uses a parent-based head sampler whose root sampling rate is configurable per component via the --otlp-sample-ratio flag (or the CD_<COMPONENT>_OTLP_SAMPLE_RATIO environment variable). The flag defaults to 1.0 (sample every trace), so for most deployments behaviour is unchanged.

There are two behavioural differences to be aware of:

Note

Sampling is now propagated across services. A sampling decision made by the service that starts a trace (for example the application controller) is honored by every downstream service the trace context flows into (repo-server, commit-server). This keeps each trace whole instead of being partially sampled across process boundaries. Set the same --otlp-sample-ratio on all components to get a consistent rate.

Warning

An inbound "not sampled" decision is now honored. Because the sampler is parent-based, a request that already carries a W3C traceparent marked not sampled is no longer recorded, even with --otlp-sample-ratio=1.0. Under the old AlwaysSample behaviour such requests were recorded regardless. This only affects deployments where an upstream proxy, gateway, or client injects trace context into requests to cd-server; if nothing upstream propagates traceparent, every trace is still rooted in Hanzo CD and sampled at the configured ratio.

Values supplied to --otlp-sample-ratio outside the [0.0, 1.0] range (or NaN) are rejected at startup with an error, so a misconfigured flag fails fast rather than silently disabling or exceeding sampling. When the ratio is set via the CD_<COMPONENT>_OTLP_SAMPLE_RATIO environment variable instead, an invalid or out-of-range value is ignored and the default (1.0) is used (a warning is logged).

3.6 KiB Raw Permalink Blame History