Setting disk_free_limit.relative = 1.0 does not work

[aayushsrivastava]

Describe the bug

I am following the production-ready example for setting up a RabbitMQ cluster.

When I set the disk_free_limit.relative = 1.0 config in rabbitmq.additionalConfig, the low disk water mark remains 2GB.

To Reproduce

Create a new cluster with the Operator. The relevant snippet of the manifest:

spec:
    rabbitmq:
        additionalConfig: |
            disk_free_limit.relative = 1.0

rabbitmqctl eval 'application:get_env(rabbit, disk_free_limit).' returns {ok,"2GB"}

Expected behavior
rabbitmqctl eval 'application:get_env(rabbit, disk_free_limit).' should return {ok, {mem_relative,1.0}}

Screenshots

If applicable, add screenshots to help explain your problem.

Version and environment information

• RabbitMQ: 3.13.6
• RabbitMQ Cluster Operator: 2.10.0
• Kubernetes: 1.29
• Cloud provider or hardware configuration: AWS

Additional context

I think this is related to #412.

disk_free_limit.absolute is set in 10-operatorDefaults.conf
When I set disk_free_limit.relative in 90-userDefinedConfiguration.conf, the absolute value is preferred by RabbitMQ.

The above behaviour is documented here:

When both disk_free_limit.absolute and disk_free_limit.relative values are set by accident, in all supported RabbitMQ versions, the former will take precedence.

[Zerpet]

This is working as intended. See rabbitmq/rabbitmq-server#6535

In summary, absolute takes precedence over relative. Relative in container environments can lead to surprising results, since the memory available to RabbitMQ is given by the cgroups. The cgroup reported memory depends on the kubernetes resources configuration, and there are cases where the memory reported by the cgroup is the entire VM memory e.g. when limits and requests are set to empty object.

It is safer to set by default an absolute value of 2GB, which is 20% of the default PVC capacity claim, 10GB. If you'd like to change the limit, setting the absolute value accordingly to your PV capacity is the way to go.

[aayushsrivastava]

That makes sense to me.

I think the production-ready example should be updated to use the absolute config in that case because it has no effect in its current state.

The production checklist also mentions that disk_free_limit should be at least equal to the high memory watermark. Since, I know the memory set to kubernetes resources, I'll base it on that instead of PV capacity.