Federated rollouts¶

A federated rollout is a rollout that targets agents on multiple peers in one operator action. The originating peer coordinates; each target peer applies the change locally with its own audit trail and local approval policy.

When to use¶

• A change you want to apply uniformly across regions.
• Time-coordinated rollouts (the same canary cohort across peers goes first).
• A single dashboard view of the rollout's progress for a multi-region change.

Pre-requisites¶

• Federation peers registered on both sides (see Registering a peer).
• The same Configuration (or equivalent) Published on every peer. Federated rollouts do not push configuration content across peers — each peer must already have the version. The cleanest way is to source the configurations from the same Git repo via GitOps on each peer.
• The same group name on every peer, or per-peer group overrides at rollout creation time.

Creating¶

Rollouts → New federated rollout:

• Configuration — pick a configuration that exists on every target peer. Ampora checks ahead of time and refuses if the version is missing on any peer.
• Peers — select which peers participate. Local-only is also a valid selection.
• Per-peer group — defaults to "same group name on each peer"; override per peer if your group naming diverges.
• Strategy — same set as local rollouts (Batch, Percentage, Canary step-up). The strategy applies per peer; pace is the same across peers.
• Coordination — Independent (each peer advances on its own timer) or Synchronized (all peers wait for the slowest before advancing).

Authorization¶

The originating operator must have Admin on the originating peer and a corresponding identity / role on every target peer. Federation does not bypass per-peer RBAC — the federated rollout itself is created on the originating peer and requested on each target peer; each target peer's RBAC and approval rules apply.

If a target peer's policy or approval flow blocks, that peer's leg of the rollout sits in PendingApproval until resolved. Other peers' legs continue.

Audit trail¶

A federated rollout produces:

• one FederatedRollout row on the originating peer,
• one Rollout row on each target peer (linked to the federated rollout via a FederationRolloutRef),
• per-peer audit events on each peer for the start / pause / resume / rollback,
• a Federation.RolloutInitiated audit event on the originating peer.

A query for "what changed in the eu-region cluster yesterday" still shows the local Rollout rows on eu-region — federation does not hide them.

Operator controls¶

• Pause — pauses every target peer's leg.
• Pause this peer only — pauses one peer's leg.
• Resume — resumes every paused leg.
• Rollback — initiates rollback on every peer.
• Abort — aborts on every peer.

These propagate via federation outbound calls, which are themselves audited.

Failure modes¶

Limitations (current)¶

• Federated rollouts can only target peers that the originating peer has registered. Transitive federation ("rollout from A reaches a peer of B that A does not know") is not supported.
• Cross-peer drift detection is not aggregated — each peer's drift is local.
• Federated rollouts are an Admin-only feature today.