[bitnami/rabbitmq-cluster-operator]: Two services with the same name
Name and Version
bitnami/rabbitmq 4.3.22
What architecture are you using?
None
What steps will reproduce the bug?
- run
helm template rabbitmq-cluster-operator . --set msgTopologyOperator.metrics.service.enabled=true > out.yaml - search in the file and you will find two services with the name
rabbitmq-cluster-operator-rabbitmq-messaging-topology-operator(metrics and webhook)
Are you using any custom parameters or values?
--set msgTopologyOperator.metrics.service.enabled=true
What is the expected behavior?
Each service have its own name
What do you see instead?
Two services with the same name
Additional information
The issue happens because these two lines return the same value because of how long the names are:
{{ printf "%s-metrics" (include "rmqco.msgTopologyOperator.fullname" .) | trunc 63 | trimSuffix "-" }}
{{ template "rmqco.msgTopologyOperator.webhook.fullname" . }}
I think the service differentiator name should not be part of the truncation.
p.s. I usually make the release name equal to the chart name when using bitnami charts, to avoid having longer names (because the chart name gets affixed to the release name if they don't match), which is how I got this issue.
Thank you for bringing this issue to our attention. We appreciate your involvement! If you're interested in contributing a solution, we welcome you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.
Your contribution will greatly benefit the community. Feel free to reach out if you have any questions or need assistance.
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.
Not staleSent from my iPhoneOn Sep 25, 2024, at 4:27 AM, github-actions[bot] @.***> wrote: This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
Hint: This is because rabbitmq-cluster-operator-rabbitmq-messaging-topology-operator is already 62 chars, the template adds a hyphen at the end, so its 63, and the namespace is appended.
Right after that, the namespace is truncated away again (trunc 63) and the hyphen at the end is removed by templating (trimSuffix "-"), leading to the name being the same no matter what namespace should have been there.
A quick fix for us was that we set .Values.msgTopologyOperator.fullnameOverride to only be messaging-topology-operator. This can lead to identification-problems, however, if there are multiple of these in a cluster.
I suggest to think about a better and shorter default naming.
@jonasbadstuebner that’s exactly what we ended up doing. Do you want to collaborate on a solution and open a PR?
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.
Not stale
@jonasbadstuebner that’s exactly what we ended up doing. Do you want to collaborate on a solution and open a PR?
I don't have the insights needed to decide on the best overall solution. Depending on how the HelmChart/Operator in general is used, it could make sense to either fix it by default or introduce an optional flag for this exact problem.
Since this broke very easily and the setup is the same for everyone in the regards of Kubernetes restrictions, I would prefer a change in default behavior and not a flag that is absolutely necessary to activate.
My suggestion would be to change the appended name from messaging-topology-operator to mto and rabbitmq-mto only. That would safe enough characters for the real name of the service.
https://github.com/bitnami/charts/blob/d7c67b926bf3546097193e79677d5601692eb461/bitnami/rabbitmq-cluster-operator/templates/_helpers.tpl#L19-L27
I don't like to abbreviate too much, but we cannot remove the prefix of the name, because that would lead to clashing names if you have more than 1 topology operator deployed.
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.
Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.