Aias00 opened a new issue, #4346: URL: https://github.com/apache/rocketmq-dashboard/issues/4346
## Problem Studio intentionally connects to operator-provided NameServer addresses, but the cluster configuration form does not explain which address forms are supported. Operators deploying RocketMQ behind a load balancer or in Kubernetes may incorrectly assume Studio requires a Pod IP or a Kubernetes discovery integration. The configured address can already be any address reachable from Studio, including an SLB/VIP, a headless Service DNS name, or a comma-separated NameServer list. This capability is not discoverable in the current form. ## Expected behavior - Explain that Studio connects directly to the configured NameServer address. - Document supported examples: SLB/VIP, headless Service DNS, and comma-separated addresses. - Keep the guidance visible near the existing cluster/NameServer form. - Use the existing `InfoBanner` and localized Chinese/English text. - Do not add Kubernetes API access, automatic discovery, background synchronization, RBAC, or new backend configuration. ## Acceptance criteria - The cluster form shows the address guidance in Chinese and English. - The guidance makes the connectivity boundary clear: the address must be reachable from the Studio server. - Existing cluster creation and update behavior is unchanged. - Focused form tests, the frontend build, lint, and formatting checks pass. ## Context This is the scoped UX follow-up requested by the maintainer when closing the Kubernetes discovery direction in #3133. The broader Kubernetes integration issue #3132 is closed as not planned. -- 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]
