Build/run RabbitMQ with self-contained ERTS?

[John Simpson]

We are building our in-house Erlang apps with ERTS included as part of the OTP bundle. This allows us to run multiple Erlang apps, which use different versions of Erlang, on the same machine, and without requiring a system-wide Erlang install (other than on the build machines).

Is there a way to compile RabbitMQ to do this? If so, is there a reason NOT to do it this way by default? This would save a lot of hassle for users:

* Users who otherwise have no reason to use Erlang at all, won't have to worry about hunting down the correct version of Erlang, or worrying about the differences between 21.x and 22.x, or having to worry about upgrading Erlang as part of upgrading RabbitMQ.

* Users who already have Erlang on their systems for other reasons, won't have to worry about version conflicts between RabbitMQ and other apps.

I'm about 99.9% sure I'm not the first person to ever ask about this, but Google wasn't very helpful in finding any other information about it (apparently Google is convinced that when I type "erts" I really mean "certs") so I'm asking here.

Thanks.

[Michael Klishin]

In master we have some significant changes that make RabbitMQ almost a standard OTP app, with a chance of making it more or less standard a bit later. We expect to backport those to 3.8 at some point (we offer no ETA).

To my knowledge you are the second person to ask for this.

Reasons not to do it include: 99.9% of RabbitMQ users do not run custom Erlang apps and (for reasons that are not rational in anyway)

know nothing or virtually nothing about Erlang. Another reason: once you tie a RabbitMQ release to an Erlang release, you are forever linked

to all the issues in that Erlang release which can *only* be mediated by upgrading RabbitMQ. As upgrades have become significantly easier and better

documented in the last year, this is less of a convincing argument but we likely won't distribute RabbitMQ as an OTP release any time soon.

Finally, FWIW many begin to ship their software exclusively in containers. Whether that makes sense for stateful data services is for another discussion

but it does mean that there often won't be any Erlang version conflicts as every app or tightly linked group of apps get their own container anyway.

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/147ca99d-189e-4ac1-bb7d-244180a62e46%40googlegroups.com.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[Michael Klishin]

Another reason to not care about this use case: even though the OTP team at Ericsson and Erlang Solutions both do an objectively lousy job of making

patch releases available to users, Erlang packaging has been mostly a solved problem for RabbitMQ users thanks to our team's efforts. These days we have:

 * Erlang Debian packages for several major versions

 * Zero dependency Erlang RPM for several major versions

 * RabbitMQ Docker image, even though not perfect, automatically rebuilds after every new Erlang and OpenSSL patch release to include them

So there aren't many reasons to bundle ERTS to make upgrades between OTP releases easier since the OTP team does not distribute builds of patch releases (which is incredibly hard to justify to anyone coming from a non-Erlang background).

Which brings us to the only reason to make OTP releases possible: Erlang users. We do want to make life easier for them but it's not a priority.

That said, we've been moving in that direction for about a year now and finishing it makes a lot of sense now. It's called the sunken cost fallacy! ;)

[Shuntian Liu]

Hi,

Just checking if it is possible run RabbitMQ with custom erlang builds at all? Do I need to build RabbitMQ from source?

Thanks!

[Luke Bakken]

Yes, you can run RabbitMQ with a custom Erlang build. The Erlang executables must be in the PATH correctly. There is no need to build RabbitMQ from source.