When a fleet or device references configuration from Git, an HTTP endpoint, or a Kubernetes secret, Red Hat Edge Manager can automatically detect upstream changes and roll out updates without manual edits to the fleet or device specification.

How automatic synchronization works

Fleets and devices can reference external configuration through configuration providers:

• Git Config Provider (gitRef)
• HTTP Config Provider (httpRef)
• Kubernetes Secret Provider (secretRef)

When automatic synchronization is active, the Red Hat Edge Manager service periodically checks those upstream sources (or watches Kubernetes secrets) for changes. When a change is detected:

• For devices in a fleet, the service creates a new fleet template version and starts a fleet rollout.
• For standalone devices (not owned by a fleet), the service re-renders the device specification directly without creating a template version.

Automatic synchronization applies only when the specification uses gitRef, secretRef, or httpRef. Inline configuration in the device specification is not synchronized from external systems.

Synchronization is enabled by default when external references are present. You do not add fields to the fleet or device specification to turn it on.

Change detection by provider type

Git and HTTP checks use the global dependenciesSync.pollInterval setting. This value specifies the minimum interval between probes for the same upstream resource. Probes for different resources are naturally spread over time because dependencies are registered at different times. Secret changes are detected near real time when the informer is running.

If a Git branch, HTTP suffix, or secret name contains template placeholders (for example {{ index .metadata.labels "target-branch" }}), Red Hat Edge Manager resolves the reference per device and triggers updates only for devices whose resolved upstream value changed.

When a device specification is rendered, Red Hat Edge Manager records the upstream fingerprint for each external configuration provider in status.dependencySync.configRefs. The lastUpdatedAt timestamp changes only when the fingerprint for that provider changes.

Template versions and rollouts

When a fleet-owned dependency changes, Red Hat Edge Manager creates a new template version and rolls it out to matching devices.

• Spec-driven template versions (after you edit the fleet template) use the name v{generation}.
• Sync-driven template versions (after an upstream dependency changes without a spec edit) use v{generation}-{short-hash}, where {short-hash} is the first eight characters of the fingerprint that triggered the sync.

Both naming patterns can coexist for the same fleet. List template versions with the following command:

flightctl get templateversions --fleetname <fleet_name>

Sync status on devices

Synchronization state is reported on each device, not on the fleet resource.

The status.dependencySync.configRefs field lists one entry per external configuration provider referenced by the device. Each entry includes:

Configuration providers that use only inline content do not appear in configRefs.

In the Red Hat Edge Manager web console, open a device to view dependency sync details in the device detail view.

Events

The following event reasons help you distinguish automatic synchronization from user-initiated specification changes:

DependencyChangeDetected events can list a fleet or a device as the involved object, depending on ownership. Event details include resourceKey (for example git:my-repo/main or http:my-config/api/v1/config) and fingerprint. DependencySyncProbeFailed events include resourceKey and errorMessage. Inspect event details in YAML:

flightctl get events --field-selector 'involvedObject.kind=Device,involvedObject.name=<device_name>,reason=DependencyChangeDetected' -o yaml

List events for a device or fleet:

flightctl get events --field-selector 'involvedObject.kind=Device,involvedObject.name=<device_name>'

Configuring synchronization

Global synchronization settings are defined in service-config.yaml on Red Hat Enterprise Linux deployments, or in the equivalent configuration mounted by your Helm release on Red Hat OpenShift Container Platform. These settings are server-side only; you do not configure dependency synchronization in fleet or device specifications.

Polling interval and task schedule

Set the minimum interval between Git and HTTP probes for the same upstream resource:

dependenciesSync:
  pollInterval: 15m

The default is 15m. The interval applies cluster-wide, not per fleet or device.

The dependency sync periodic tasks run on an internal schedule (default every 3 minutes) to discover new dependency references and retry failed probes. That task interval is not configurable in service-config.yaml; only pollInterval is user-configurable under dependenciesSync.

Kubernetes secret auto-sync

Secret synchronization requires Red Hat Edge Manager to run in the cluster where the secrets are stored.

1. Label each secret that should be watched:

   metadata:
     labels:
       flightctl.io/sync-<release_namespace>: "true"

   Replace <release_namespace> with the namespace where you installed Red Hat Edge Manager (for example flightctl.io/sync-flightctl: "true" when the release namespace is flightctl).

2. Grant the periodic service permission to list and watch secrets when secrets are not limited to the release namespace:

   On Red Hat OpenShift Container Platform, set both of the following in the Helm install YAML when you need cluster-wide secret access for sync and rendering:

   global:
     worker:
       clusterLevelSecretAccess: true
     periodic:
       clusterLevelSecretAccess: true

   For namespace-scoped access, use Role and RoleBinding resources as described in Secrets from a Kubernetes cluster in the Additional resources section.

Security considerations

• Store Git and HTTP credentials only in Repository resources or Kubernetes secrets, not in fleet or device specifications.
• Ensure Repository resources use the minimum access required (read-only Git credentials where possible).
• Probe failure events (DependencySyncProbeFailed) sanitize error messages so that tokens and passwords are not written to the event log.
• Secret synchronization uses the Kubernetes secret resourceVersion as a fingerprint; Red Hat Edge Manager does not store secret data in status.dependencySync.
• Grant clusterLevelSecretAccess to the worker and periodic services only when secrets are distributed across namespaces. Prefer namespace-scoped Role and RoleBinding resources where possible.

Viewing sync status with the CLI

Devices

View per-provider sync fingerprints on a device:

flightctl get device/<device_name> -o yaml

Inspect the status.dependencySync.configRefs block.

Fleets

Fleet resources do not include a dependencySync status block in YAML. To assess fleet-wide synchronization:

1. Review devices in the fleet:

   flightctl get devices --field-selector 'metadata.owner=Fleet/<fleet_name>'

2. Inspect the fleet resource, template versions, and events:

   flightctl get fleet/<fleet_name> -o yaml
   flightctl get templateversions --fleetname <fleet_name>
   flightctl get events --field-selector 'involvedObject.kind=Fleet,involvedObject.name=<fleet_name>'

3. For per-dependency fingerprints, inspect devices in the fleet with -o yaml as shown above.

Metrics for cluster administrators

When Prometheus scrapes the Red Hat Edge Manager periodic service, the following metrics relate to dependency synchronization:

Use flightctl_dependency_sync_informer_connected to detect secret informer disconnects. For troubleshooting, see Secret informer disconnect or not running in the Additional resources section.

For troubleshooting steps, see Troubleshooting dependency synchronization in the Additional resources section.