apache / apache/rocketmq-operator

[Feature Request] Support Manage Multi RocketMQ cluster

Open
#176 3 comments 0 reactions 0 assignees View on GitHub
enhancement
Dominant language
Go
Stars
336
Forks
128
PR merge metrics
No merged PRs in 30d

Description

## Please describe the feature you are requesting.
I propose the enhancement of the current operator to support the management of multiple RocketMQ clusters by a single operator.

## Provide any additional detail on your proposed use case for this feature.
https://github.com/apache/rocketmq-operator/blob/ad72466472819163ee9cb3562fdbfde35bd6e30b/pkg/share/share.go#L23-L38

Given the code above, our operator can only manage one RocketMQ cluster at a time (one nameservice deployment and one broker cluster). In a multi-tenant Kubernetes usage scenario, users may want to deploy multiple RocketMQ clusters in different namespaces.

## Are you currently using any workarounds to address this issue?
One potential workaround might be to deploy one operator with one RocketMQ cluster in a single namespace. However, this is not a very efficient strategy in a Kubernetes environment.

## If there are some sub-tasks using -[] for each subtask and create a corresponding issue to map to the sub task:

- [sub-task1](null): Refactor the code to eliminate shared variables in https://github.com/apache/rocketmq-operator/blob/master/pkg/share/share.go
- [sub-task2](null): Implement support for multiple RocketMQ clusters.
- [sub-task3](null): Add a RocketMQ API to manage all resources (this is not a high priority at the moment).

Contributor guide

No contributing guide indexed for this repository

Research direction

Read pkg/share/share.go first, then use the linked sub-tasks as the work breakdown. Confirm how the current shared variables constrain one nameservice deployment and broker cluster, with completion defined as eliminating those shared variables and supporting multiple clusters in different namespaces. The RocketMQ API sub-task is explicitly low priority.

Written by the indexing model from the issue text.

Assessment

Tech stack
go, kubernetes
Domain
infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.