During the 3.8.4 cycle we have backported rabbit_env to v3.8.x.
Instead of messing with env variable prefixing, it tries both
RABBITMQ_{VAR} and {VAR} environment variables. However,
in CLI tools node name currently only picks up RABBITMQ_NODENAME,
so environments where node name has to be explicitly configured
via rabbitmq-env.conf:
NODENAME=rabbit@our.custom.hostname
would not pick this node name up. RABBITMQ_NODENAME had to be added
as a workaround.
With this change the behavior of CLI tools and the server is closer.
Note that this updates a few places which used Config.get_option/2
to get a "default node name" which more often than not ended up
being a node prefix ("rabbit"). Those tests had to be updated
to use Config.default/1.
During the 3.8.4 cycle we have backported
rabbit_envto v3.8.x. Instead of messing with env variable prefixing, it tries both RABBITMQ_{VAR} and {VAR} environment variables. However, in CLI tools node name currently only picks up RABBITMQ_NODENAME, so environments where node name has to be explicitly configured via rabbitmq-env.conf:would not pick this node name up. RABBITMQ_NODENAME had to be added as a workaround.
With this change the behavior of CLI tools and the server is closer.
Note that this updates a few places which used
Config.get_option/2to get a "default node name" which more often than not ended up being a node prefix ("rabbit"). Those tests had to be updated to useConfig.default/1.Closes #421. References 29ecca24e5345f532e27945b0c94018e2665dfec, 4243d9a0b3487eaba1f54bf459363420b501e9f0, #278.