RockteMQ-AI commented on issue #235: URL: https://github.com/apache/rocketmq-operator/issues/235#issuecomment-5308353871
**Issue Evaluation** Category: `enhancement` | Status: **Evaluated** **Feasibility:** Feasible **Scope:** CRD types for Broker, Controller, and NameService — add `podAnnotations` field to their respective template specs **Compatibility:** Non-breaking — additive field in CRD spec; existing deployments without annotations are unaffected This is a standard Kubernetes operator pattern. Both [RabbitMQ Cluster Operator](https://github.com/rabbitmq/cluster-operator/blob/main/api/v1beta1/rabbitmqcluster_types.go#L77) and [Strimzi Kafka Operator](https://github.com/strimzi/strimzi-kafka-operator/blob/main/api/src/main/java/io/strimzi/api/kafka/model/common/template/PodTemplate.java#L46) support this, and the use case (Spiderpool static IP annotations) is legitimate. **Suggested approach:** 1. Add `podAnnotations map[string]string` to the Pod template struct for each component (Broker, Controller, NameService). 2. Merge user-supplied annotations into the Pod spec during StatefulSet/Deployment construction, taking care not to overwrite system-managed annotations (e.g. `kubectl.kubernetes.io/last-applied-configuration`). 3. Add a corresponding field in the CRD validation schema (if using structural schemas). 4. Update Helm chart values to expose `podAnnotations` per component for users not using raw CRDs. Note: this issue has been open since December 2024. A maintainer ack on scope would help before implementation begins. --- *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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
