Go library for the HyperFleet desire contract and store backends. A desire is the declarative intent for a single Kubernetes resource on a management cluster (apply, delete, or read). Store backends persist that intent and its status so appliers can reconcile resources without ManifestWork-style bulk transport.
It collaborates with other HyperFleet components:
- API is the source of truth for fleet resource desired state and aggregated status
- Sentinel polls the API and publishes CloudEvents that drive reconciliation
- Adapter listens for those events, applies changes, and reports status back to the API
Prerequisites: Go 1.26+, Make
make build
make test
make lintRun make help for the full list of targets.
The binary follows the same command and configuration conventions as the other HyperFleet services:
make runLocal runs are not in a pod, so the election namespace comes from
POD_NAMESPACE; the Makefile defaults it to hyperfleet. Override it with
make run POD_NAMESPACE=<namespace>.
Override the default configuration path with make run CONFIG=/path/to/applier.yaml. The shared
Kubernetes discovery cache is invalidated using discovery_refresh_interval, allowing newly
installed CRDs to be reconciled without restarting the applier. All three controllers use
poll_interval.
make run uses $KUBECONFIG when set, otherwise $HOME/.kube/config. Override it with
make run KUBE_CONFIG_PATH=/path/to/kubeconfig. Redis must already be reachable at the URL in the
configuration file (or supplied through HYPERFLEET_REDIS_URL).
Configuration precedence follows the HyperFleet convention: command-line flags, then
HYPERFLEET_* environment variables, then YAML, then defaults. Use
bin/hyperfleet-applier config-dump --config configs/applier.yaml to inspect the merged,
redacted configuration.
Leader election is always enabled: only the lease holder runs the apply, delete, and read loops, and standby replicas wait. Namespace resolution, lease timings, failover, and deployment constraints are documented in Replica model and leader election.
| Package | Description |
|---|---|
pkg/desire |
Desire types (ApplyDesire, DeleteDesire, ReadDesire), identity validation, SpecStore / StatusStore interfaces |
pkg/desire/store/memory |
In-memory store for unit tests |
pkg/desire/store/redis |
Redis-backed store with WATCH/MULTI/EXEC CAS |
pkg/desire/store/conformance |
Shared conformance suite exercised by both backends |
go get github.com/openshift-hyperfleet/hyperfleet-applier| Resource | Description |
|---|---|
make help |
Build, test, lint, format, and verify targets |
pkg/desire package docs |
Desire model, identity rules, and store contracts |
| Resource | Description |
|---|---|
| HyperFleet Architecture | System design |
| HyperFleet API Spec | API contract |
| Broker Library | Messaging abstraction |
| Infrastructure | Deployment automation |
Credentials are stored scoped to the applier's own partition by convention. Cryptographic enforcement of that scoping arrives with the production backends.
As part of https://redhat.atlassian.net/browse/HYPERFLEET-1601 - decided to defer FIPS compliant images until compliance requirement comes in.
If want to build a FIPS compliant applier image -- add these Go variables to the Dockerfile and Makefile
CGO_ENABLED=1 and GOEXPERIMENT=strictfipsruntime go ...Reference on this: https://developers.redhat.com/articles/2025/01/23/fips-mode-red-hat-go-toolset
The applier's ClusterRole uses an explicit GVR allowlist. See Deriving the RBAC allowlist in the chart README for how to compute and configure it.
- Verify you're a member of the
openshift-hyperfleetorganization - Confirm you're added to the hyperfleet team
- Code reviews and approvals are managed through the OWNERS file
For access issues, contact a repository administrator or organization owner.
This project is licensed under the Apache License 2.0. See LICENSE for details.