Skip to main content

Module overlayd

Module overlayd 

Source
Expand description

IPC wire protocol between the main zlayer daemon and zlayer-overlayd.

zlayer-overlayd is a standalone, long-lived daemon that owns every mechanism touching the overlay/network plane (the WireGuard device + adapter, peers, AllowedIPs/service subnets, IP allocation, DNS, NAT, Linux bridges + veth/netns attach, and the Windows HCN Internal network + endpoints). The main zlayer daemon keeps the cluster brain (Raft, the scheduler, the service registry, container/HCS process lifecycle) and drives overlayd over a length-prefixed-JSON IPC channel (a Unix domain socket on Unix, a named pipe on Windows).

This module is that channel’s wire contract — the only thing both sides must agree on. It lives in zlayer-types (a leaf crate) so the daemon, the overlayd server, and the overlayd client can all depend on it without a dependency cycle.

§Framing

One connection multiplexes request/response and server→client event push. Each frame is a OverlaydFrame serialized as JSON and written with a u32 little-endian length prefix (the framing itself lives in zlayer-overlayd’s transport module, not here). The main daemon sends OverlaydFrame::Requests each carrying a client-chosen id; overlayd replies with a OverlaydFrame::Response echoing that id, and may at any time push an unsolicited OverlaydFrame::Event.

§Wire-type conventions

  • Windows HCN GUIDs cross the wire as bare lowercase strings (aabbccdd-eeff-..., no braces) — windows::core::GUID is not serde-serializable and zlayer-types must not depend on windows.
  • CIDRs cross as String (e.g. "10.200.0.0/28"); endpoints as String ("host:port", kept textual so an unresolved/hostname endpoint survives).
  • Addresses use std::net::IpAddr (serde-serializable via std).

Re-exports§

pub use crate::overlay::OverlayConfig;
pub use crate::overlay::OverlayMode;

Structs§

AttachResult
Result of OverlaydRequest::AttachContainer.
DedicatedServiceStatus
Status of a single dedicated per-service overlay device within a StatusSnapshot.
GuestOverlayConfig
Overlay identity returned for a guest-managed attach (AttachHandle::GuestManagedOverlaydResponse::GuestConfig).
PeerSpec
A WireGuard peer to add to the base overlay. Mirrors zlayer_overlay::PeerInfo but with wire-safe field types.
PeerStatus
Per-peer status within a StatusSnapshot.
ServiceOverlayInfo
Identity of a dedicated per-service overlay device, reported by SetupServiceOverlay once Dedicated mode is wired up. Shared-mode setups leave the wg_*/overlay_ip/subnet fields None.
StatusSnapshot
Diagnostics snapshot returned by OverlaydRequest::Status.

Enums§

AttachHandle
Identifies the container overlayd must wire into the overlay. The agent owns the container’s process/compute-system lifecycle and hands overlayd just enough to attach it.
OverlaydEvent
An unsolicited notification pushed from overlayd to the main daemon.
OverlaydFrame
A multiplexed frame on the overlayd IPC connection.
OverlaydRequest
A request from the main daemon to overlayd.
OverlaydResponse
overlayd’s answer to an OverlaydRequest.
PeerScope
Which overlay device a peer / AllowedIP op targets. Global (default, and the only value pre-Dedicated senders emit) = the single cluster transport. Service = that service’s dedicated per-service transport.

Constants§

PROTOCOL_VERSION
Wire-protocol version. Bump on any breaking change to the frame/request/ response/event shapes so a version-skewed daemon/overlayd pair can detect the mismatch instead of silently misparsing.