Docs: User should be discouraged to install rabbitmq with homebrew

[gjoalland13]

MacOS user should be discouraged to install rabbitmq with homebrew as it install the latest version of erlang with it, which is not compatible with rabbitmq, causing the rabbitmq-server to crash without any reason.

Instead, one can install it from the generic binary build or with a docker image.

[danielhollas]

Is this a new issue or has this been the state of things for a while?

This seems like an issue with homebrew that should be reported to them and (hopefully) fixed? We can document this, but such documentation would become outdated as soon as they fix it? Unless we think that rabbitmq from homebrew is busted more fundamentally or generally unreliable?

[gjoalland13]

I have seen it for at least 6 months. My understanding of it is that simply the homebrew formula is not correct as it blindly install the most recent version of erlang and probably could be easily fixed.

The alternative to using homebrew for MacOS installation requires using the Generic Unix Binary Build. Not only it is annoying but seems more involved, to ensure the correct linkage of erlang with rabbitmq in particular. So, generally speaking if one could avoid using the GUBB, imo they should.

For the MacOS users, maybe at least one could just add a warning in the documentation that a user should perform brew info erlang and verify its compability with respect to the erlang compatibilty table. What do you think?

[danielhollas]

For the MacOS users, maybe at least one could just add a warning in the documentation that a user should perform brew info erlang and verify its compability with respect to the erlang compatibilty table. What do you think?

That seems very reasonable!

[r0hansaxena]

@gjoalland13 @danielhollas I've made the additions to the docs in the PR, could you please review it?

[mbercx]

Thanks for raising the issue @gjoalland13! I know you had more troubles with RabbitMQ in general (not just with HomeBrew, also the generic binary). This HomeBrew specific issue is unrelated then?

I've used HomeBrew to install RabbitMQ on all my macOS machines, and never ran into any issue. Could you specify which versions of rabbitmq and erlang are conflicting? And does the rabbitmq-server crash immediately, or intermittently? I want to see if I can reproduce the issue before we adapt our documentation.

EDIT: I updated both rabbitmq and erlang with brew upgrade, and didn't run into any issues after some basic testing. It does seem from the documentation you mentioned that there is still an issue with Khepri, the metadata store. As I understand it, this should only really affect usage when you're running a cluster, not when running a single node as we do with AiiDA. So since RabbitMQ release 4.2 (17 Feb), installing RabbitMQ with HomeBrew should be fine?

I think recommending against using HomeBrew - which is the easier approach I'd say? - because of a temporary compatibility issue is unnecessary. We could add a note/warning that the HomeBrew install could lead to an incompatible version of erlang and how to troubleshoot it/try another install approach.

[gjoalland13]

To the best of my knowledge, this is unrelated to the daemon issue I am currently facing.

I was previously experiencing issues with RabbitMQ version 4.2.3 and Erlang 28.3.1. My RabbitMQ server would either crash immediately or after running for some time. I no longer encounter this issue when installing Erlang 27.3.4.8 using Homebrew and RabbitMQ 4.2.3 using the Generic Unix Binary Build.

That being said, I am a bit puzzled by the fact that you do not encounter any issues after running brew upgrade. I agree that it might be excessive to completely discourage the use of Homebrew, but I tend to think that new macOS users should at least be warned about potential incompatibilities.

I have yet to check whether using Docker resolves all my RabbitMQ problems. I hope it does. I will let you know, and if it does indeed solve the issue, perhaps macOS users could be encouraged to use this approach instead of Homebrew.

[mbercx]

Thanks for the extra details @gjoalland13! I'm also not sure why I can't reproduce the issue on my machine. I'm curious if @giovannipizzi , @t-reents or @Minotakm have had any issues with RabbitMQ, in case they use HomeBrew to install it.

In any case I fully agree adding a note/warning is a solid idea. I just don't want to push a more complicated install on users in case Homebrew works fine for them. Also I'd have to be convinced that the Homebrew version is somehow less stable than the Docker one before encouraging users based on one experience. Installing AiiDA is already tricky enough without also requiring Docker.

I'm looking into the daemon issue, but as always, it's tricky to really understand what is happening based on the logs sometimes. I'll respond shortly on Discourse. :)

[r0hansaxena]

@mbercx I agree we shouldn't overcomplicate things since Homebrew works fine for most users.
Should I revert the PR to recommend Homebrew first again, and just add a warning below it about the brew upgrade Erlang mismatch? I can move Docker and the binary build down as alternatives.
Let me know if that sounds good and I'll make the changes.

[mbercx]

Thanks @r0hansaxena, that sounds good to me, but let's maybe hold off to see if we can get more feedback from other macOS users (are you one, by any chance?). Perhaps if I'm the only lucky one where Homebrew works fine, we should put e.g. the binary build first.

[t-reents]

Hi @mbercx!

I just briefly checked the discussion here and might missed a few details. While installing rabbitmq via homebrew also smoothly worked for me for a long time, the package got automatically upgraded to the latest versionat some point (this happened while I was updating another unrelated package, and homebrew apparently did a general update/upgrade so to say).

Afterwards, I also had some incompatibilities du to that. It took me quite some time, and I'm not a 100% if I installed everything from scratch or not. I just checked and found an old ChatGPT chat, where I tried to debug this.
Again, not sure whether it solved the problem in the end, but I used the following to install a specific version of rabbitmq:

brew tap-new $USER/local-rabbitmq

brew extract --version=3.13.7 rabbitmq $USER/local-rabbitmq

[mbercx]

Thanks @t-reents! Interesting, so we can potentially even install an older version of RabbitMQ that doesn't require the extra configuration step.

One thing to definitely consider: if we can avoid the extra configuration of the consumer_timeout. A Docker approach does allow to run an older version of RabbitMQ.

EDIT: Another is also how lightweight the solution is. Running Docker/podman just for RabbitMQ is rather bulky.