You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Introduce the Border control-plane resource: a machine-managed NAT
gateway carrying its SNAT/DNAT rules inline (jsonb[]) on one flat
resource, with a PaaS builder, user API, BorderBuilder unit tests and
network.border.* permission seeds bound to project owners.
Deployment shapes, calque of net_lb.type:
* default -> border_agent capability on the core node's agent;
* node set -> border_node pinned to that node's agent
(distributed egress, e.g. a managed realm node);
* type.kind: core -> border_node on a dedicated gateway VM the iaas
builder provisions (net_border_iaas -> target_node_set).
The core node's agent serves only border_agent: border_node is always
pinned by the builder, and its driver ships where the data plane lives
(realm node / border VM image), mirroring paas_lb_agent vs paas_lb_node.
ec-bootstrap-templates restores /etc configs from persisted copies, so
the border additions to the universal agent template would never reach
an upgraded stand. Hoist the scheduler-section rewrite out of the
repo-proxy migration (only reachable on pre-repo-proxy stands) into
_ensure_ua_config_current(), run unconditionally on every boot: rewrite
[universal_agent_scheduler], insert BorderAgentCapabilityDriver into
caps_drivers, sync the persisted copy and try-restart the agent
services. Covered by unit tests.
Also: single 0066 init migration (final net_border schema + permission
seeds), gcl_sdk 3.1.0, drop core's own '/' static route on the shared
LB vhost, point the CLI realm endpoint docs at Core's LB.
Signed-off-by: George Melikov <mail@gmelikov.ru>
0 commit comments