Frontier Platform Engineering Agent — OpenStack to Netris and SONiC

The Frontier Platform Engineering Agent turns OpenStack network changes into deterministic fabric operations on Netris and SONiC through MCP, with audit.

The Frontier Platform Engineering Agent keeps the physical fabric in step with OpenStack. OpenStack (VitroAI) is the source of truth: when a tenant creates or deletes a network, the agent turns that change into fabric-contract operations and applies them through the fabric’s MCP server. It drives two fabrics from the same desired state: Netris, through its controller, and SONiC, with no controller. One OpenStack network appears on both. No model decides or applies changes. The engine is deterministic, and every operation is audited.

For which network changes reach the physical fabric at all, see When the Platform Engineering Agent Touches the Underlay. For the SONiC results and their caveats, see OpenStack to SONiC.

How it works

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#0c332d','primaryTextColor':'#e6edf3','primaryBorderColor':'#2dd4bf','lineColor':'#8b949e','secondaryColor':'#11203a','tertiaryColor':'#161b22','fontSize':'14px'}}}%% graph TD A["Neutron (VitroAI, ML2/OVN)"] --> B["OpenStack MCP server
(13 tools)"] B --> C["Listener
(polls Neutron every 3 s)"] C --> D["Desired state
project → VRF · network + IPv4 subnet → segment"] D --> E["Contract engine
plan/apply · scope guard · audit · drift detection"] E --> F["Netris adapter"] F --> G["Netris MCP server"] G --> H["Netris controller 4.6"] E --> I["SONiC adapter"] I --> J["SONiC MCP server"] J --> K["SONiC leaves"]

The fabric contract

Contract operation Netris realization (Netris MCP tools)
Ensure VRF Create tenant and VPC (the VPC VNI is the L3 VNI)
Ensure segment Create subnet (IPAM allocation and common subnet), then a V-Net with gateway on the site
Delete segment Delete V-Net, then subnet and allocation
Delete VRF Delete VPC, then its tenant
Attach / detach port Reported as unsupported (no port tools or switch hardware yet)
Read state List VPCs, list V-Nets, per-VPC IPAM

On SONiC, the same operations become VRFs, VLAN and VXLAN segments and switch-port memberships on every leaf; see OpenStack to SONiC. The pools, NAT, ACL, static-route and load-balancer services are Netris only. Each adapter implements the operations its fabric supports and reports the rest as unsupported. Adding a fabric means adding an adapter over that fabric’s MCP server. The engine and the OpenStack side stay unchanged.

The Neutron VXLAN IDs are OVN overlay identifiers and the Netris VNIs are fabric identifiers. They are independent by design: the contract carries intent, not wire IDs.

Live results

On Netris, all results are control-plane tests against the Netris 4.6 controller. No switches are attached to the Netris site, so no tenant traffic has crossed the fabric yet.

Test Result Time
Create an OpenStack network Pass. Tenant, VPC, IPAM allocation and subnet, and an active V-Net with gateway appear on Netris automatically About 4 s
Delete the OpenStack network Pass. V-Net, subnet, allocation and VPC are removed from Netris About 3 s
Out-of-band change on Netris Pass. A V-Net deleted directly on Netris is reported as missing_on_fabric on the next drift cycle, and reconcile restores it Next drift cycle (17 s)
Write guards Pass. Writes without confirm=true, and names outside the configured scope, are refused —
After reconcile Plan and drift are both empty —

Service parity

The parity release is merged, and Netris MCP server v0.2.0, which carries its tools, is deployed through GitOps. Each change went through the full path, from OpenStack through the agent and the Netris MCP server to the controller. With ML2/OVN, tenant traffic is carried by OVN over the fabric, so these Netris objects are not in the tenant data path today.

Feature OpenStack change Result on Netris
Router to VRF A router with interfaces on two networks Both networks land in one VRF named after the router. Router mode is off by default and must be enabled
Isolated network A network on no router Its own VRF
Public IP pool An external network subnet A NAT pool, or a load-balancer pool for a subnet named for load balancing
Source NAT A router gateway with SNAT enabled One SNAT rule per attached IPv4 subnet
Floating IP Create, release, create A 1:1 DNAT rule created, deleted and recreated
Security groups Rules added to a group; a second group created and deleted One ACL per IPv4 rule per segment; deleting a group removes only its own ACLs. ACLs are created on the controller but not enforced today, because the site’s default ACL policy is permit
Static routes Router extra routes added, changed and removed Netris static routes created, replaced and deleted to match
L4 load balancer — Create, list and delete work through the Netris MCP server, and reconcile removes an orphaned one. The OpenStack load-balancer mapping is unit-tested only
L2-only network A network with no subnet A V-Net with no gateway
IPv6 A dual-stack network The V-Net carries both gateways
Rename A network renamed The VPC and V-Net are renamed in place, with the same identifiers

Building this flow found a defect in Netris MCP server v0.1.0: every create tool failed when called through MCP. v0.1.1 fixed it and added a regression test. v0.1.2 added a delete-tenant tool, so deleting a VRF also removes its Netris tenant. The current release, v0.2.0, adds the service tools for pools, NAT, ACLs, static routes, L4 load balancers and rename. See Netris — Agents & FFO Integration for the server’s verified tools.

Deployment

The agent runs in-cluster on the platform’s RKE2 Kubernetes cluster. It is deployed through GitOps with Argo CD (a CNCF project), and its OpenStack MCP server is registered in Remuda, the platform’s MCP registry. The same in-cluster agent drives both fabrics. The SONiC MCP server runs next to the switches and is not yet in-cluster.

Design choices

  • OpenStack access is through MCP. A thin, fabric-oriented OpenStack MCP server returns all-project networks with project, provider fields, subnets, port bindings and segments in one snapshot call. Its writes need confirm=true and stay within the configured scope.
  • The event source is polling. The listener polls Neutron through MCP, so the cloud’s configuration does not change. A message-bus listener can replace polling without touching the engine.
  • The engine is deterministic. It applies operations in a fixed order (VRFs, segments, attachments, segment deletes, VRF deletes) and refuses anything outside the configured scope.
  • The design is model-agnostic. No model is in the decision or apply path.
  • Every action is audited. An append-only JSONL log, with secret scrubbing, records every plan, operation, change and drift check.

Not yet built or tested

  • Port attachment on Netris and on hardware switches
  • Data-plane traffic, tenant isolation and negative tests through a Netris-managed fabric (needs switches)
  • Enforcing security groups on the fabric, and mapping IPv6 and remote-group rules
  • On SONiC: hardware leaves and a spine, IPv6, ACLs, NAT, LAG and symmetric IRB, and in-cluster packaging of the SONiC MCP server
  • Automatic repair of drift found on cycles with no OpenStack change: built but not tested, and off on the deployed agent, so a manual reconcile repairs it today
  • Kubernetes clusters built through CAPO, through the agent
  • A message-bus (notification) listener
  • Optional LLM explanations and proposals through the Frontier llm-router
  • Least-privilege service accounts for OpenStack and Netris
  • Multi-site, scale and concurrency testing