mirror of
https://github.com/Studio-Saelix/sencho.git
synced 2026-09-04 06:35:29 +00:00
docs(fleet-sync): refresh hardening, anchor, retry, demote behaviors (#974)
The fleet-sync.mdx page reflected an earlier shape of the feature. Refreshed to cover everything the receiver and sender now do: - Both scan policies AND CVE suppressions replicate over the same channel today (was previously framed as "future" for suppressions). - Control anchor: replicas bind to the first control fingerprint and reject pushes from a different control until an admin reanchors. Documented the reanchor curl call. - Push ordering: monotonic pushedAt rejects strictly-older pushes with 409 STALE_SYNC_PUSH; legacy controls without timestamps still accepted for back-compat. - Automatic retry: the control retries failed pushes every 5 minutes for 24h and emits one warning notification per hour-long failure window for previously-working remotes. - Demote to control: documented the admin-only button and what it wipes. Replaced the "remove the node from the control" workaround with the proper flow. - Pilot-agent nodes: explicitly documented as out of fleet-sync scope. - Tiebreaker: documented lowest-id wins for ties. - Replica policy filtering: identity-scoped policies for other replicas no longer surface in this replica's UI. - Troubleshooting expanded with 409 codes (STALE_SYNC_PUSH, CONTROL_IDENTITY_MISMATCH). Cross-link added from vulnerability-scanning.mdx (Scan policies section) so anyone reading about policies finds the replication docs.
This commit is contained in:
@@ -166,6 +166,10 @@ When multiple policies match a deploy, Sencho picks the most specific one:
|
||||
|
||||
Only one policy is evaluated per deploy; use a single tight pattern rather than overlapping policies for clarity.
|
||||
|
||||
<Note>
|
||||
Policies created on a control instance replicate to every remote in the fleet automatically. See [Fleet Sync](/features/fleet-sync) for the replication, push retry, and replica demote behavior.
|
||||
</Note>
|
||||
|
||||
### Example policies
|
||||
|
||||
**Block criticals and highs in production.** A tight gate that keeps known vulnerable base images out of your production fleet.
|
||||
|
||||
Reference in New Issue
Block a user