[Feature Request] Add Motor Coordinator topology client (TOPO_TYPE=motor) for MindIE Motor standalone deployment

[dunjin]

Motivation

We want to use Patio as a sidecar in inference engine pods to register/unregister Prefill/Decode instances with a standalone MindIE Motor Coordinator on standard Kubernetes.

Currently Patio's GroupTopoClient topology layer supports two target protocols:

Client	Target	Protocol
SGLangGroupTopoClient	SGLang Router	POST {router}/workers / DELETE {router}/workers/{id}
VLLMProxyTopoClient	vLLM Proxy	POST {proxy}/instances/add

Neither matches the management-plane protocol of MindIE Motor's standalone Coordinator, so Patio cannot serve as the registration sidecar for a Motor deployment today.

Target Protocol (MindIE Motor standalone Coordinator)

MindIE Motor's Coordinator exposes a management API at port 1026 that accepts instance registration via POST /instances/refresh:

Endpoint: POST http://:1026/instances/refresh

Auth (optional, for production): header X-Motor-Management-Key:

Request body (external deployer protocol ExternalInsEventMsg):

json { "event": "add", "model_name": "Qwen2.5-7B", "dispatch_capabilities": "prefill_handoff_decode", "engine_type": "vllm", "instances": [ { "id": 1001, "role": "prefill", "endpoints": [ {"id": 0, "address": "10.0.0.5:8000"} ] } ] }

Supported event values: �dd, del, set (replace all), list (query via GET /instances)

Important implementation notes (observed in Motor source):

• engine_type is currently restricted to "vllm" only on the Motor side;
• del requires replaying the exact endpoint list used at registration (matched by
  ole + endpoint signature);
• Instance id is caller-supplied and must be globally unique (Motor's CLI derives it as STANDALONE_ID_NAMESPACE | crc32(role + sorted endpoints));
• dispatch_capabilities supports "prefill_handoff_decode" or "concurrent_engine_sync".

Proposed Change

Add a new topology client type (TOPO_TYPE=motor) that implements the existing GroupTopoClient interface:

New file: opo/client/motor_topo_client.py

• wait_engine_ready() — reuse existing /health polling (consistent with Motor's own circuit-breaker probe);

egister() — POST /instances/refresh with event=add|set, encoding worker info into ExternalInsEventMsg format;

• unregister() — POST /instances/refresh with event=del, replaying the exact endpoints registered;
• Support optional X-Motor-Management-Key via file path.

Factory update: opo/factory.py

• Add "motor" to create_topo_client(), creating MotorCoordinatorTopoClient.

New environment variables (decoupled from RBG DNS conventions)

Variable	Default	Description
MOTOR_COORDINATOR_ENDPOINT	(required)	Coordinator service hostname or IP
MOTOR_MGMT_PORT	1026	Coordinator management port
MOTOR_MGMT_API_KEY_FILE	(optional)	Path to API key file
TOPO_TYPE	"motor"	Selects the new client

Heartbeat

Keep Patio's existing periodic re-registration (default 10–30s). This also covers Motor Coordinator restart recovery — standalone mode has no Controller to re-push instance state after a restart.

Acceptance Criteria

1. With TOPO_TYPE=motor and MOTOR_COORDINATOR_ENDPOINT set, Patio registers a P/D engine pod as a routable instance, visible via GET /instances on the Coordinator mgmt port;
2. Engine pod termination triggers unregister() which removes the instance from the routing table (event=del);
3. Coordinator restart is automatically recovered by Patio's heartbeat re-register;
4. Optional X-Motor-Management-Key works when configured.

Open Questions

1. Instance ID ownership: Should the id be derived deterministically inside Patio (e.g. crc32(role + worker_endpoint)), or returned by the Coordinator on first registration?
2. SGLang support: Motor's external protocol currently accepts engine_type="vllm" only. If Patio users run SGLang as the inference engine, this blocks integration. Should this be tracked as a Motor-side issue in parallel?
3. Add/Set idempotency: Should Patio use �dd (fails on duplicate) or set (replace all, heavier) for heartbeat re-register? Motor's set replaces the entire instance list and could race with concurrent registrations.

References

• MindIE Motor standalone deployment doc: docs/zh/user_guide/deployment/standalone.md (https://gitcode.com/Ascend/MindIE-Motor)
• Motor external protocol schema: motor/common/resources/http_msg_spec.py → ExternalInsEventMsg
• Motor registration CLI: motor/coordinator/register.py

I'm happy to share detailed Motor protocol specs, provide a test Coordinator endpoint, or review a PoC patch.

[dunjin]

Cross-referencing the corresponding MindIE Motor side discussion: https://gitcode.com/Ascend/MindIE-Motor/issues/614

Motor 社区已确认这是一个双方共建的 Feature Request，并在该 Issue 中同步跟踪 Patio 适配所需的协议确认项（engine_type 放开、实例 ID 策略、幂等语义等）。后续 Motor 侧的技术讨论请见上方链接。