`spec.tls.disableNonTLSListeners` is applied but not persisted in the resource definition

[vmignot]

Describe the bug

spec.tls.disableNonTLSListeners is behaving as expected, but is not persisted in the resource definition

To Reproduce

Steps to reproduce the behavior:

1. Edit an existing RabbitmqCluster with TLS enabled and set spec.tls.disableNonTLSListeners=false
2. You should see your ports opening
3. Now read your RabbitmqCluster: spec.tls.disableNonTLSListeners is not set

Expected behavior
The parameter should be persisted, to keep track of state.

Version and environment information

• RabbitMQ: 4.0.7-management
• RabbitMQ Cluster Operator: 2.16.0 and 2.17.0
• Kubernetes: 1.32.0
• Cloud provider or hardware configuration: EKS

Additional context

Installed CRDs: https://github.com/rabbitmq/cluster-operator/blob/v2.17.0/config/crd/bases/rabbitmq.com_rabbitmqclusters.yaml

[Zerpet]

The root cause is that disableNonTLSListeners is a concrete type bool, not a pointer. This means that we can't distinguish between false and not set at all. Practically, it makes no difference "not set" or "false", they have the same behaviour. The reason you don't see it in the manifest is because of how Go handles YAML, and the decorator omitempty, which removes fields "not set"; in this case "not set" and "false" are the same thing.

I'm not inclined to make this change, to be honest. It's a cosmetic change, and the change will break some of the users out there that consume this project as a library.

[vmignot]

Hello, and thanks for your reply!

To me it's not a real problem, as I am wrapping my RabbitMqClusters in a custom chart, so it's just the matter of adding an if, now that I have confirmation of this limitation. Furthermore, I do not feel able to make a PR on this matter.

Yet, IMHO, we have here a case in which our Desired State principle is flaky (= true means true, "" means false, false is an edge-case), that should at least be documented more clearly.

[Zerpet]

Yet, IMHO, we have here a case in which our Desired State principle is flaky (= true means true, "" means false, false is an edge-case), that should at least be documented more clearly.

Well, the field type is boolean, therefore true means true, false means false, and "" in invalid. Kubernetes or Go YAML marshalling, I'm not sure which one (or a combination of both), strips the invalid field, resulting in defaulting to false.

Edit: actually, we can add this detail in the operator TLS configuration docs, as it is not very clear in the documentation.