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 Argo CD's own view of the Application — sync status, health status, operation phase, the synced revision, and a message — written to the deployment Space as a confighub.com/live-status annotation. 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.

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 the cluster was actually given. 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 Space. 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.