lizhimins opened a new issue, #4301:
URL: https://github.com/apache/rocketmq-dashboard/issues/4301

   ### Motivation
   
   Studio has no written model for how nameservers, physical clusters and 
Studio instances relate, and the ownership rules for topics/groups are only 
implicit in the DB unique key `(cluster_id, instance_id, name)`. Three concrete 
problems follow from that:
   
   - A physical cluster can only be registered as a single instance, which is 
not what operators need.
   - The same topic name can exist under two instances. `create`/`import` then 
silently overwrites the physical configuration belonging to the other instance, 
and `delete` leaves a zombie management record behind: the other instance still 
lists the topic, but any operation on it fails with "route not found" (which 
the query-error-grading rule reports as an empty state rather than an error, 
making it harder to spot).
   - The tool layer addresses instances by `cluster`, conflating the physical 
cluster with the Studio-side ownership concept.
   
   ### Expected
   
   A specification document under `docs/` recording:
   
   - the hierarchy — one nameserver may be shared by multiple clusters, one 
cluster may host multiple instances, and `instanceId` is a Studio-side 
ownership concept only (open-source RocketMQ has no namespace/instanceId)
   - topic and group names are globally unique within one Studio deployment, so 
the DB unique key belongs on `name` alone rather than on `(cluster_id, 
instance_id, name)`
   - the behaviour this implies for create/import/update/delete/list/describe, 
including rejecting cross-instance ownership conflicts with 409
   - the external parameter naming the tool layer should use: `instanceId` as 
an explicit required parameter, `topicName`/`groupName` for resource names, and 
no `namespace`
   - environments that need identical resource names (dev/staging/prod) should 
run separate Studio deployments
   
   The document records the specification only. The DB unique key change, the 
ownership checks and the data migration for existing rows are tracked 
separately and are not implemented yet.


-- 
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]

Reply via email to