zhaohai666 opened a new issue, #421:
URL: https://github.com/apache/rocketmq-dashboard/issues/421
# Issue Title
**[RIP-1 + RIP-3] Control Plane 5.0: Unified Architecture Refactor + LLM
Native Integration (CLI / MCP / Embedded Chat)**
---
## Issue Description
This tracking issue covers the end-to-end delivery of RocketMQ Control Plane
5.0 in the `apache/rocketmq-dashboard` repository, integrating **RIP-1 (Unified
Control Plane Architecture)** and **RIP-3 (LLM Native Integration)** as one
coordinated workstream.
The initiative rebuilds the dashboard with a standardized three-layer
abstraction architecture to enable unified management across 4.0 direct, 5.0
Proxy Local/Cluster, and cloud-managed RocketMQ clusters. Built entirely on top
of RIP-1 abstractions, RIP-3 extends the control plane with three AI-native
interaction modes — `rmqctl` CLI, standard MCP Server, and in-console embedded
LLM chat — all sharing a single unified tool schema, auth system and metadata
layer.
---
## 1. Background & Motivation
The current `rocketmq-dashboard v2.1.0` faces structural limitations in the
cloud-native and AI-Native era:
1. **Architecture entanglement**: 4.0 and 5.0 code paths are tightly coupled
without standardized abstraction layers, causing recurring compatibility
defects (#380, #381, #390, #401, #402, #403).
2. **Single interaction mode**: Only Web UI is available; no standardized
CLI or programmatic API for automation, scripting and third-party O&M system
integration.
3. **Zero AI agent accessibility**: No standard interface for LLM agents /
IDE copilots to invoke RocketMQ operational capabilities, forcing teams to
build custom wrappers.
4. **Inconsistent auth & observability**: Incomplete ACL 1.0/2.0 adaptation
for multi-architecture clusters; no native Prometheus integration for unified
observability.
---
## 2. Core Goals
1. Establish a standard three-layer abstraction architecture to fully shield
underlying architecture and protocol differences.
2. Maintain 100% feature parity with v2.1.0, fix all known critical defects,
and guarantee full backward compatibility.
3. Support unified management of four deployment modes: 4.0 direct, 5.0
Proxy Local, 5.0 Proxy Cluster, and cloud-managed instances.
4. Deliver three LLM-native interaction forms: `rmqctl` CLI, standard MCP
Server, and in-console embedded chat.
5. Unify ACL 1.0 + 2.0 auth chain, encrypted credential storage and audit
logging across all interaction modes.
6. Provide native Prometheus observability with standard dashboards and
production-ready alert rule templates.
---
## 3. Non-Goals
- No self-developed LLM inference service; users bring their own model API
keys.
- No standalone backend admin APIs; all capabilities reuse the unified
abstraction layer.
- Does not replace the traditional Web UI; LLM features are optional
supplements and can be fully disabled.
- Does not modify Broker / NameServer core logic in the `apache/rocketmq`
main repository.
- Does not implement a standalone alerting engine; reuses users' existing
Prometheus / Alertmanager stack.
---
## 4. Core Architecture Overview
```
┌─────────────────────────────────────────────────────────────┐
│ Business Layer (Web UI + CLI + MCP Server + LLM Chat) │
│ Capability-driven dynamic rendering & multi-modal access │
└───────────────────────────┬─────────────────────────────────┘
│
┌───────────────────────────▼─────────────────────────────────┐
│ MetadataProvider Domain Layer (META-01) │
│ Namespace / Topic / Group / ACL / Client / LiteTopic │
│ Cloud vendor SPI extension point │
└───────────────────────────┬─────────────────────────────────┘
│
┌───────────────────────────▼─────────────────────────────────┐
│ AdminClient Protocol Layer (ARCH-01) │
│ Remoting / gRPC / Cloud OpenAPI multi-protocol support │
│ Standard auth hook injection (AUTH-01) │
└───────────────────────────┬─────────────────────────────────┘
│
┌─────────────────┼─────────────────┐
▼ ▼ ▼
4.0 NameSrv+Broker 5.0 Proxy Cluster Cloud Mgmt API
```
---
## 5. Scope of Work
### Part A: RIP-1 — Control Plane 5.0 Core Modules
| Module ID | Module Name | Key Deliverables |
|-----------|-------------|------------------|
| **BASE-01** | Baseline Parity | Full migration of all 11 v2.1.0 feature
categories; fix 7 known critical defects |
| **ARCH-01** | Multi-Architecture Support | `ClusterProvider`,
`AdminClient`, `MetadataProvider` SPI abstractions; implementations for v4 /
v5-Local / v5-Cluster / cloud modes; runtime architecture switching |
| **META-01** | Metadata Management | Namespace CRUD & resource tree
navigation; strong-type management for 5 Topic types; prefix-aggregated
LiteTopic lifecycle management; cloud vendor SPI extension point |
| **AUTH-01** | Full-Chain ACL | Dual adaptation for ACL 1.0 (Remoting) and
ACL 2.0 (gRPC); hybrid mode auto-detection; encrypted cluster-level
credentials; hot-reload support; standardized audit logging |
| **CLIENT-01** | Dual-Protocol Clients | Protocol-agnostic unified client
view (Remoting + gRPC); client detail drawer with subscriptions, heartbeat
timeline and consumption progress |
| **METRICS-01** | Observability | Prometheus datasource integration; PromQL
proxy with auth & audit; 10+ built-in standard dashboards; Grafana JSON export;
20+ built-in alert rule templates |
### Part B: RIP-3 — LLM Native Integration
> All capabilities 100% reuse RIP-1 abstractions. No independent backend
APIs are introduced.
#### Phase 1: `rmqctl` CLI
- 30 tools across 9 resource groups (cluster, namespace, topic, group,
message, client, acl, broker, metrics)
- kubectl-style multi-cluster context management, config persisted at
`~/.rmqctl/config.yaml`
- Structured output support: `table` / `json` / `yaml`; unified structured
error model `{code, message, hint}`
- Three-tier risk enforcement: L1 (silent read), L2 (dry-run + confirm), L3
(default blocked, explicit opt-in required)
- Local audit logging and encrypted credential storage
#### Phase 2: Standard MCP Server
- 1:1 tool mapping with CLI commands, zero schema drift
- Dual transport support: `stdio` (for Claude Desktop, Cursor, etc.) and
`SSE` (for web clients)
- `rmq.capabilities` capability detection tool to prevent LLM hallucination
- Built-in SecurityGate enforcing permission rules and dry-run / apply
two-phase execution
- Reuses RIP-1 AUTH-01 auth chain for all tool calls
#### Phase 3: Console Embedded LLM Chat
- 3 entry points: homepage full-width command bar, global `Cmd/Ctrl+K`
shortcut, detail-page sidebar chat with auto context injection
- Backend MCP Bridge; API keys are never exposed to the frontend
- Structured result rendering with native UI components and deep links to
resource detail pages
- Consistent safety guardrails with CLI / MCP
- Graceful degradation: falls back to global search when no LLM provider is
configured
- 6 supported providers: OpenAI, Azure OpenAI, AWS Bedrock, DeepSeek, Qwen,
Ollama
---
## 6. Acceptance Criteria
### RIP-1 Core
- [ ] Three-layer SPI abstractions are fully defined and implemented for all
four architecture modes
- [ ] 100% feature parity with v2.1.0; all 7 known defects are fixed
- [ ] Namespace, 5 topic types and LiteTopic management work correctly on
5.0 clusters
- [ ] ACL 1.0 and ACL 2.0 clusters are both fully supported with
auto-detection
- [ ] Unified dual-protocol client view displays Remoting and gRPC clients
correctly
- [ ] Prometheus datasource integration works; standard dashboards render
correctly
### RIP-3 LLM Integration
- [ ] `rmqctl` CLI covers all core operational capabilities; multi-cluster
context works correctly
- [ ] MCP Server supports stdio / SSE transports; successfully integrates
with mainstream MCP clients
- [ ] In-console LLM chat works end-to-end; dry-run confirmation and safety
guardrails are enforced
- [ ] All capabilities 100% reuse RIP-1 abstractions; no duplicate backend
logic
- [ ] Graceful degradation works for 4.0 clusters and unconfigured LLM
environments
### Overall Quality
- [ ] Full backward compatibility; existing v2.1.0 REST APIs remain unchanged
- [ ] Unit test coverage ≥ 80% for core modules
- [ ] End-to-end verification passes on 4.0 / 5.0-Local / 5.0-Cluster
clusters
- [ ] Complete documentation: user guide, API reference and best practices
---
## 7. Related RIPs & Dependencies
- **RIP-2 (Proxy Admin API)**: Companion implementation in the
`apache/rocketmq` main repository. CLIENT-01 uses telemetry metrics as a
transition view today, and will seamlessly switch to the RIP-2 final view once
released.
- **Dependency rules**:
- RIP-3 depends on RIP-1's core abstraction layer.
- RIP-1 does not depend on RIP-3 and is fully functional on its own.
- RIP-1 and RIP-2 can be developed in parallel.
---
## 8. Contribution Notes
- All code is delivered in the `apache/rocketmq-dashboard` repository.
- All submissions must follow Apache RocketMQ community coding standards and
contribution guidelines.
- Sub-tasks can be claimed by commenting on this issue; please raise design
questions and technical discussions in the corresponding RIP threads.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
