Skip to content

Live Resources

"Live resources" are the actual resources instantiated in the system under management, as distinct from the configuration in ConfigHub that describes them.

For example, a Config Unit may represent a Kubernetes workload — a Deployment, Service, Ingress, and related resources. The Unit is the configuration; the objects running in the cluster are the live resources.

A Unit becomes live by being included in a published Release, which a GitOps operator pulls and reconciles into the cluster. It stops being live when the Release is withdrawn, or when the operator stops applying it. See Releases and OCI delivery.

What ConfigHub knows about live resources

ConfigHub records what it published: each Release captures exactly which revision of each Unit it contains, and publishing advances each Unit's LastReleasedRevisionNum. So "what configuration has been released for this cluster, and when?" always has a precise answer.

Live status from the cluster

What happened after the operator pulled a Release can be reported back, but only if something in the cluster does the reporting. ConfigHub itself never connects to your cluster.

argobot is the supported way to do this for Argo CD. It is an event consumer that runs in the cluster, and it does two things: it syncs the corresponding Argo CD Application as soon as a Release is published, so a deploy takes effect immediately rather than at Argo's next reconcile; and it watches Applications and reports their status back to ConfigHub.

cub cluster up installs argobot by default (pass --no-argobot to skip it). For a cluster you set up yourself, installing it is optional.

The status argobot reports is recorded on the Release the Application is running, as the Release's LiveStatus. argobot finds that Release by the revision Argo CD synced, which is the Release's ManifestDigest. LiveStatus holds:

  • Sync, Health and Operation, normalized so that they mean the same whatever tool reported them: Sync is Synced, OutOfSync or Unknown; Health is Healthy, Progressing, Degraded, Suspended, Missing or Unknown; Operation is Running, Succeeded or Failed, or absent when no operation has run. These are what promotion gates read.
  • ReporterSync, ReporterHealth and ReporterOperation, the same three in the tool's own words, such as Argo CD's Error or Terminating operation phases.
  • Reporter, such as argobot, DataSource, such as the Argo CD Application's name, a Message, and ObservedAt.

Because the status belongs to a Release, a Release that has just been published has none until argobot reports on it, rather than showing the status of the Release before it. cub release list --space <space> shows each Release's sync and health, and cub release get the rest:

cub release list --space my-app-prod

So with argobot installed, "did the last Release actually land, and is the Application healthy?" is answerable from ConfigHub. Without it, ConfigHub knows only what it published, and your operator's own UI is the place to look.

Tracing a live resource to its Release

Every Kubernetes resource in a Release carries a confighub.com/origin annotation, whose value is JSON naming the Space, the Unit, and the Unit's revision it came from:

confighub.com/origin: '{"spaceId":"...","spaceSlug":"my-app-prod","unitId":"...","unitSlug":"my-app","revisionNum":7}'

It does not name the Release. The same revision of a Unit is bundled into every Release that captures it, so the content alone cannot say which one is running; the Release is identified by the OCI manifest the operator pulled. Without a status reporter, check a rollout one step at a time, each step telling you only about its own layer:

  1. The Release exists. cub release list --space <space> shows it, with the first digits of its ManifestDigest. If there is none, the publish was refused, or found nothing changed; see what blocks a publish.
  2. The operator has synced it. The revision the operator reports as synced, such as an Argo CD Application's sync revision or a Flux OCIRepository's artifact revision, is the Release's ManifestDigest. A different digest means the operator is behind, or cannot pull the Release; a pull it is not allowed shows up as an authentication error in the operator.
  3. The workloads are healthy. The objects' conditions, read with kubectl get and kubectl describe, say whether the configuration works. Their confighub.com/origin annotations say which Unit revision each object came from, which you can compare with the revisions the Release bundled.

Any tool that deploys Releases can report the same way, by patching the Release's LiveStatus. Writing it needs Edit on the Release, which EditChildren on the Release's Target grants. cub cluster up grants it to the service account argobot runs as, along with the View and ViewChildren that let it read the Spaces releasing to the Target and pull their Releases.

Bringing a cluster-side change back

When someone changes a resource in the cluster, cub k8s refresh brings that change back into the Unit that describes it, one resource at a time:

cub k8s refresh deployment my-app --namespace my-namespace

There is no --space flag: the resource is traced back to its Unit by the confighub.com/origin annotation the Release stamped on it.

Refresh strips everything that is cluster state rather than configuration — status, managedFields, cluster-internal metadata, and every field owned only by a controller — then diffs what is left against the Unit's LastReleasedRevisionNum, the revision last published for it. Diffing against the released revision rather than the head is what separates cluster-side drift from changes made in ConfigHub since. The drift is then patched onto the head, restricted to that resource and to the paths that actually changed; a path the Unit protects as a local override is reported as a conflict instead of being overwritten. --dry-run shows what it would do.

A Unit that has never been released has nothing to diff against, and refresh says so rather than treating the whole live object as a change.

This replaces the earlier per-Unit refresh operation, which merged live state into a Unit's data as part of a push-based apply model that no longer exists.

What ConfigHub still does not do

Drift is not reconciled automatically. Argo CD detects drift and reports it through the sync status argobot forwards, but ConfigHub takes no action on it. Bringing a cluster-side change back into configuration is the deliberate, per-resource cub k8s refresh above, never something that happens on its own.

Live status is not per-Unit. argobot reports per Argo CD Application, onto the Release it is running. An earlier model had ConfigHub reach into the cluster directly and record what it found on each Unit, in fields named LiveState, LiveData, BridgeState, SyncStatus, and Drift. That mechanism was removed and so were the fields: a Unit carries no per-Unit runtime state at all, and a query naming one of them is rejected as an unrecognized attribute.