Peer relationship management: edit allow-lists without re-registering + per-peer disable (feeds #150) #176
Labels
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Cordy/Cairn#176
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Two dogfood notes (Nikola), both about managing an existing peering:
PATCH /api/v1/admin/peering/peers/{name}updating the four lists (sendUsers, sendGroups, recvUsers, recvGroups) in place, key and URL untouched, plus the UI edit affordance.peeringEnabled). Wanted: pause a single peer without deleting its configuration — anenabledflag on the peer entry, enforced on both planes (inbound auth check and outbound send eligibility), so one misbehaving or paused relationship doesn't force a choice between "all peering off" and "delete the trust".Both land naturally in the #150 panel redesign (one relationship card per peer — the card gets an edit mode and an on/off toggle). Backend first: registry mutations + gRPC/send-path enforcement + tests; the card UI consumes them. Fail-closed semantics as everywhere in peering: a disabled peer answers exactly like an unknown one on the wire.
Triage: build-solo, verify-tandem. Edit a peer's sender allow-list without re-registering + per-peer disable (the runtime data behind #150's card). Buildable solo (peer registry already persists allow-lists); testing the actual gating needs a live peer. Do alongside #150.
Greenlit — build first (backend enabler for #150 + #125 discovery).
Confirmed as-specified:
PATCH /api/v1/admin/peering/peers/{name}updating the four lists (sendUsers,sendGroups,recvUsers,recvGroups) in place; key and URL untouched. Registry mutation method + tests.enabledflag, enforced fail-closed on both planes: a disabled peer answers inbound (Hello/PrepareTransfer/ the newListRecipients) exactly like an unknown one, and is ineligible outbound (CanSend→ false). gRPC + send-path enforcement + tests.Fail-closed semantics match the rest of peering. This lands before #150 (the card consumes both) and before the #125 discovery RPC (which must also honour the
enabledflag).Both asks shipped in the v0.6.20/v0.6.21 peering panel v2 (#150) and verified live while completing #244:
PATCH /api/v1/admin/peering/peers/{name}, key and URL untouched, no delete-and-re-register.enabledflag on the peer entry, enforced fail-closed on both planes (inbound auth viaRegistry.IsDisabled; outbound send eligibility +CanReceive/CanReceiveSpacehonorDisabled). A disabled peer answers exactly like an unknown one on the wire.Closing as done.