You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@rocketmq.apache.org by "Aias00 (via GitHub)" <gi...@apache.org> on 2026/09/15 14:45:39 UTC
[I] [Studio][Feature] Persist and apply Ops RocketMQ connection settings at runtime [rocketmq-dashboard]
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: commits-unsubscribe@rocketmq.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Studio][Feature] Persist and apply Ops RocketMQ connection settings at runtime [rocketmq-dashboard]
Posted by "RockteMQ-AI (via GitHub)" <gi...@apache.org>.
RockteMQ-AI commented on issue #4348:
URL: https://github.com/apache/rocketmq-dashboard/issues/4348#issuecomment-5683609566
**Issue Evaluation**
Category: `enhancement` | Status: **Evaluated**
**Feasibility:** Feasible
**Scope:** Studio frontend (Ops page, global store, routing guards) + minor backend addition (`/ops/testConnection` endpoint)
**Compatibility:** No breaking changes — adds new persistence layer without modifying existing behavior
This is a well-specified feature request. The current behavior (settings lost on refresh, no validation on Save) is a real UX gap for Studio users managing multiple clusters.
**Key design points:**
- Persisting connection settings to backend storage (file or DB) is the right approach for multi-session durability
- Adding a `testConnection` API before save prevents persisting invalid configurations
- Routing guard ensuring at least one valid connection exists before entering the main UI is a good safety net
- The proposed options for storage (JSON file vs. DB table) both work; JSON file is simpler for the initial implementation
This enhancement would significantly improve the Studio onboarding and daily operational experience.
---
*Automated evaluation by RockteMQ-AI*
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Studio][Feature] Persist and apply Ops RocketMQ connection settings at runtime [rocketmq-dashboard]
Posted by "Aias00 (via GitHub)" <gi...@apache.org>.
Aias00 closed issue #4348: [Studio][Feature] Persist and apply Ops RocketMQ connection settings at runtime
URL: https://github.com/apache/rocketmq-dashboard/issues/4348
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Studio][Feature] Persist and apply Ops RocketMQ connection settings at runtime [rocketmq-dashboard]
Posted by "Aias00 (via GitHub)" <gi...@apache.org>.
Aias00 commented on issue #4348:
URL: https://github.com/apache/rocketmq-dashboard/issues/4348#issuecomment-5760229246
Closing this proposal after the product-direction review on #4387. Runtime-editing a default/no-instance RocketMQ connection conflicts with the current instance model, which requires explicit `instanceId` routing and intentionally keeps these Ops mutations fail-closed. The persistence and deployment portions will not proceed. The independent in-flight client retirement safety has moved to #4755 and PR #4761.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] [Studio][Feature] Persist and apply Ops RocketMQ connection settings at runtime [rocketmq-dashboard]
Posted by "Aias00 (via GitHub)" <gi...@apache.org>.
Aias00 commented on issue #4348:
URL: https://github.com/apache/rocketmq-dashboard/issues/4348#issuecomment-5682856946
Design security correction: the global AuthInterceptor enforces admin-only POST only while login is required. When `studio.auth.login-required=false` (or the runtime login policy is disabled), the interceptor skips authentication entirely. The implementation must therefore enforce `AuthenticatedUserContext.currentUserIsAdmin()` in each managed Ops mutation itself; anonymous and non-admin callers must get 403 even when the Ops runtime flag is enabled. Add service and controller tests for this case. This replaces the unconditional interceptor assumption in the Scope section above.
--
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: commits-unsubscribe@rocketmq.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org