Aias00 opened a new issue, #4348: URL: https://github.com/apache/rocketmq-dashboard/issues/4348
## Problem `OpsService` hardcodes `configurationAvailable=false` and its five mutation endpoints return HTTP 501. This is deliberate fail-closed behavior: earlier simulated writes reported success without changing RocketMQ clients. The Ops page already disables controls when the backend reports the configuration unavailable, but operators cannot manage Studio's default Apache RocketMQ connection. There are separate Spring-bound defaults (`studio.cluster.admin.namesrv-addr` and `studio.rocketmq.namesrv-addr`), a persisted NameServer registry, and long-lived admin/producer/consumer client caches. Editing the registry or a bean alone is not an effective runtime connection update. VIP and TLS are client transport settings, not NameServer server settings. ## Scope and ownership - Manage **Studio's default Apache RocketMQ connection** only. Do not rewrite instance-specific endpoints, credentials, NameServer processes, or the NameServer registry. - Keep `studio.cluster.admin` credentials and TLS key/trust material in deployment-owned configuration; never persist or reveal secrets via Ops. - Preserve the existing `/api/ops/*` routes and `OpsHomeVO` envelope. Existing auth interceptor restricts POST writes to admins. - The feature is disabled by default until deployment explicitly enables runtime management; when disabled or the backing configuration cannot be loaded, keep `configurationAvailable=false` and fail closed. ## Proposed design 1. Add a distinct persisted Ops runtime configuration (separate key from general settings) for an allowlisted NameServer address list, selected default address, VIP mode, and TLS mode. Bootstrap from externalized defaults without overwriting them; record the active source and define how a persisted override is applied on startup and across Studio replicas. Reject blank/malformed/duplicate addresses, selecting a non-member, deleting the active or last address, and invalid payloads. 2. Provide one effective default-connection resolver consumed by both default cluster discovery/admin providers and the default producer/consumer paths. Do not alter instance-scoped provider routing or credential identity. 3. Apply `ClientConfig.setNamesrvAddr`, `setVipChannelEnabled`, and `setUseTLS` **before** a new `DefaultMQAdminExt`/producer/consumer starts. On a runtime change, ensure the next operation does not reuse a client created with the previous address/transport settings. Avoid disrupting another instance that happens to use the old address; key/evict caches with that ownership in mind. 4. Reject enabling TLS unless the deployment explicitly disables RocketMQ's insecure TLS test mode and supplies a server-authentication/trust policy. RocketMQ 5.5 defaults to insecure trust in test mode; a Boolean stored by Ops must not silently make an unauthenticated TLS connection. No TLS certificate/key contents in DB, logs, audit, or responses. 5. Return current effective values in `GET /api/ops/homePage`. All five POST routes change effective behavior (or return an actionable 4xx/501), never just a stored/UI value. Record administrator audit entries without secrets. Keep the UI's existing capability gate; PR #4154 adds client-side preflight and is complementary, not a backend implementation. ## Implementation and verification - Introduce a small Ops configuration repository/model and runtime resolver; use the existing settings storage pattern without changing general/LLM settings. - Wire both default NameServer configuration sources and client creation to the same effective resolver. Validate updates before committing; use cache generation or targeted release so transport settings actually change. - Unit/integration tests: bootstrapped and persisted reads, five write routes, validation/conflicts, active/last address protection, disabled/DB-failure behavior, VIP/TLS before-start application, insecure TLS rejection, cache change without affecting instance-specific connections, admin access and audit. - Run targeted backend tests, Checkstyle, full backend suite in an isolated datasource, and focused frontend tests/build/lint when UI behavior changes. ## Acceptance criteria - With explicit deployment enablement, a successful Ops write is reflected by `homePage` and by subsequent real default-client configuration; restart restores persisted values. - Without enablement or secure TLS prerequisites, writes fail closed and do not mutate the effective client state. - Existing instance-specific endpoints/credentials and NameServer registry CRUD remain unchanged. - No mutation reports success while the client continues using the old address/VIP/TLS settings. ## Out of scope - Provisioning, restarting, or editing NameServer server processes; that is a separate deployment-control-plane issue. - Creating Kubernetes/Docker/SSH integrations in Studio. - Persisting TLS key/cert/trust material or RocketMQ admin credentials in Studio settings. -- 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]
