Aias00 opened a new issue, #4311:
URL: https://github.com/apache/rocketmq-dashboard/issues/4311
## Problem
The Studio cluster UI exposes Broker restart, NameServer lifecycle, and
Proxy restart endpoints, but `ClusterService` currently validates the target
and then returns HTTP 501. RocketMQ's admin protocol does not provide a
portable process restart, upgrade, or deletion API: those operations belong to
the deployment control plane (Docker Compose, Kubernetes, SSH, or an operations
platform).
The current behavior leaves the UI with lifecycle actions that cannot
perform a real operation, while implementing one deployment mechanism directly
inside Studio would couple the server to a specific runtime and create an
unsafe command-execution surface.
## Goals
- Dispatch real Broker / NameServer / Proxy lifecycle operations through a
deployment-controlled adapter.
- Keep the existing cluster and node target validation before any external
operation is attempted.
- Fail closed with an actionable 501 when no lifecycle adapter is configured
or an operation is not allowlisted.
- Return a bounded, auditable dispatch result without claiming that the
remote process is healthy.
- Keep the adapter independent from Docker, Kubernetes, SSH, and any one
operations platform.
## Proposed design
### 1. Lifecycle SPI
Add a `cluster.lifecycle` package with:
- `LifecycleOperation`: `BROKER_RESTART`, `NAMESERVER_RESTART`,
`NAMESERVER_UPGRADE`, `NAMESERVER_DELETE`, `PROXY_RESTART`.
- `LifecycleOperationRequest`: operation, cluster id, target address or
broker name, optional target version, and a generated request id.
- `LifecycleOperationResult`: operation, target, request id, accepted
status, and bounded message.
- `LifecycleOperationExecutor`: one interface for dispatching a validated
request.
`ClusterService` remains responsible for resolving and validating the target
from the discovered `ClusterVO`. The executor only receives a validated request
and never receives a raw command string from HTTP input.
### 2. Configured process adapter
The first implementation is a `ProcessLifecycleOperationExecutor` backed by
a server-side executable configured as an argument vector. It uses
`ProcessBuilder`, never a shell string, and passes operation-specific values as
separate arguments:
```yaml
studio:
lifecycle:
enabled: false
executable: ""
working-directory: ""
timeout: PT30S
max-output-bytes: 8192
allowed-operations: []
```
The executable is responsible for invoking Docker Compose, Kubernetes, SSH,
or an operations API in the deployment environment. Studio only starts it,
enforces the timeout/output bound, and interprets exit code 0 as accepted. A
non-zero exit is a failed dispatch; a timeout is a gateway timeout. No shell
expansion, environment interpolation, or request-controlled executable is
permitted.
The default remains disabled and empty, so an unconfigured deployment cannot
execute arbitrary host commands. The adapter must also reject an operation that
is not explicitly allowlisted.
### 3. HTTP contract
Keep the existing lifecycle routes and target validation. Replace the
boolean success placeholder with a typed dispatch result while preserving the
common `Result<T>` envelope. Existing callers can continue to treat
`accepted=true` as a successful dispatch.
Every attempted operation records an audit entry with operation, cluster,
target, request id, result, and bounded executor output. The response and audit
entry describe dispatch only; health convergence and rollback remain the
responsibility of the external executor.
### 4. Safety and compatibility
- Existing 400/404 validation behavior remains unchanged.
- Disabled, missing, or non-allowlisted adapters return 501 without starting
a process.
- Command arguments are constructed from validated fields; no user-supplied
command or shell fragment is accepted.
- The target version is required only for NameServer upgrade.
- Delete and restart operations remain admin-only through the existing
authentication interceptor.
- No lifecycle operation is exposed through the MCP catalog in this
iteration.
## Implementation plan
1. Add lifecycle value objects, configuration properties, executor
interface, and the bounded `ProcessBuilder` implementation.
2. Inject the executor into `ClusterService`, delegate the five supported
operations after existing target checks, and record success/failure audit
entries.
3. Update Broker, NameServer, and Proxy controller responses to return the
typed dispatch result.
4. Add unit tests for argument construction, allowlist enforcement, disabled
mode, non-zero exit, timeout, output truncation, target validation, and audit
behavior.
5. Add `application.yml` / `.env.example` documentation and a deployment
adapter contract example without enabling command execution by default.
## Acceptance criteria
- A configured executable receives the expected operation and validated
target arguments for all five operations.
- No process is started when lifecycle execution is disabled, unconfigured,
or not allowlisted.
- Non-zero exit and timeout responses are surfaced as structured errors and
audited.
- Existing target-not-found and malformed-request tests remain green.
- The full backend test suite and Checkstyle pass.
- Documentation clearly states that the executable is the deployment control
plane and that Studio reports dispatch, not health convergence.
## Out of scope
- Implementing Docker, Kubernetes, or SSH orchestration inside Studio.
- Polling process health or persisting long-running operation state.
- Automatic rollback or multi-node rolling-restart policy.
- Exposing lifecycle mutation tools through MCP before a separate risk and
confirmation contract is reviewed.
--
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]
