Aias00 opened a new issue, #4355: URL: https://github.com/apache/rocketmq-dashboard/issues/4355
## Problem `POST /api/nameservers/create` and `/api/nameservers/update` exist, but `ClusterService` returns HTTP 501 after checking the cluster/target. Separately, `/api/nameservers/registry/*` only maintains Studio's address directory; writing a registry row does not create or reconfigure a NameServer process. RocketMQ Admin does not offer a portable process-provisioning protocol across Docker, Kubernetes, SSH and managed operations platforms. The guarded lifecycle executor proposed in #4311 and implemented by PR #4312 handles restart/upgrade/delete, but deliberately excludes create/update. The frontend update request already carries `newAddr`; the backend `UpdateNameServerDTO` currently discards that field, so the desired update cannot reach any executor. ## Scope and semantics - **Create** requests a deployment-owned controller to provision a new NameServer at one `addr` for an existing discovered cluster; `version` is optional deployment metadata. It does not add a registry entry or claim the new process is healthy. - **Update** changes the deployment endpoint from an existing discovered `addr` to a distinct `newAddr`; optional `version` is passed as deployment metadata. A version-only change uses the existing `/upgrade` route rather than silently changing this operation's meaning. No in-process topology or registry snapshot is mutated on dispatch. - Reuse `LifecycleOperationExecutor` from #4312 with `NAMESERVER_CREATE` and `NAMESERVER_UPDATE`. No Docker/Kubernetes/SSH SDK, shell command, or HTTP-supplied executable is added to Studio. - These operations require explicit enablement and allowlisting. The deployment executable maps cluster/address/version values to its controlled inventory; it must reject unknown targets, enforce idempotency/placement/rollback policy, and must not trust `addr` as a host command. ## Design and adapter contract 1. Extend the existing lifecycle request/enum and fixed `ProcessBuilder` command vector: ```text nameserver-create --cluster-id <cluster> --target <new-address> [--target-version <version>] --request-id <uuid> nameserver-update --cluster-id <cluster> --target <existing-address> --target-address <new-address> [--target-version <version>] --request-id <uuid> ``` Here `--target-address` means the replacement endpoint for update; for Broker restart it remains the discovered Broker endpoint. Arguments are individual tokens; no shell expansion. 2. Validate before dispatch: cluster exists; create address is one valid `host:port` or `[IPv6]:port` and is not already in the discovered cluster; update old address exists, replacement is one valid address, differs from old address and does not collide with another discovered NameServer. Return existing 400/404 behavior, and 409 on a duplicate/replacement conflict. The adapter still owns deployment inventory validation because discovery alone cannot prove infrastructure ownership. 3. Change the two routes to `Result<LifecycleOperationResult>` (dispatch result, not synthetic `NameServerVO` or a false success `Void`). Generated request IDs and success/failure audit entries follow the five existing lifecycle actions. Non-allowlisted/disabled returns 501, process failure returns 502, timeout returns 504. Exit 0 means only that the deployment controller accepted the request; no health convergence is asserted. 4. Map frontend `newAddr` and optional `version` into the backend DTO and typed result. Existing mock mode may update its in-memory topology, but live mode must refresh discovery after a successful dispatch and must not synthesize a running NameServer. ## Acceptance criteria and tests - Both operations reach the configured executable with exact validated argument vectors and can be independently allowlisted. - Missing/invalid/duplicate targets, version-only update, disabled/unconfigured executors and non-admin requests never start an executable. - Exit/timeout/output bounds, generated request IDs and audit result match #4312's behavior. Retry may dispatch twice unless the deployment adapter deduplicates; the API must not promise exactly-once provisioning. - Controller/service, executor and frontend API/service tests cover create/update responses, validation and the `newAddr` mapping; Checkstyle, full backend suite and frontend tests/build/lint pass. - Deployment docs show the new operation names and explicitly distinguish process provisioning from registry CRUD. ## Dependency and PR shape This is a separate follow-up to #4311 / PR #4312. Its implementation will reuse that SPI; while #4312 remains unmerged, the follow-up PR may temporarily include the dependency commits in its diff against `rocketmq-studio`. After #4312 merges, the follow-up diff should contain only the two new operations. Do not copy or reimplement the process runner. ## Out of scope - Built-in Docker/Kubernetes/SSH provisioning adapters, deployment manifests or creating physical infrastructure from only an address. - Editing arbitrary NameServer runtime configuration properties; `getNameServerConfig`/`updateNameServerConfig` is a separate admin-protocol operation. - Health polling, rolling deployment policy or automatic rollback inside Studio. -- 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]
