For 3.7.x, please use at least OTP 20.3.x

[michaelklishin]

As far as I can tell this image provisions Erlang 19.3 for RabbitMQ 3.7.x. I don't see any reason not to provision at least 20.3 or 21.x for a few reasons:

• Single digit % of installations (that we can track) use OTP 19.3. Only the most recent patch levels are safe (older have known bugs catastrophic to RabbitMQ)
• 19.x support will be dropped in November 2018

Team RabbitMQ now provides our own Debian Erlang package "remixes" that are published to Bintray for a variety of distributions, old and new. They should be entirely compatible with the official Debian packages as far as the user goes but you get the latest and greatest versions some 30 minutes after they are tagged in the erlang/otp repo.

I'd recommend using that repository and go with OTP 21.0.x.

[michaelklishin]

I'd be happy to contribute a PR that makes the switch in case @tianon and @yosifkit find this a good idea.

[gerhard]

+1 on using the RabbitMQ Debian repo for Erlang.

rabbitmq:3.7.7 docker image is using Erlang/OTP 20.3.8.3

docker run --rm rabbitmq:3.7.7 bash -c 'dpkg -l erlang-nox'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version           Architecture Description
+++-==============-=================-============-==========================================================
ii  erlang-nox     1:20.3.8.3+dfsg-1 all          Erlang/OTP applications that don't require X Window System

[tianon]

That sounds pretty awesome; how many architectures does it support? Our current architecture list is pretty long. 😬

[gerhard]

Only amd64 & i386 according to the build pipeline (private). @dumbbell can correct me if I am wrong.

Have you considered basing the rabbitmq image on erlang:21? I can see that it supports almost all architectures that the rabbitmq image supports.

[dumbbell]

The list is even more limited than what @gerhard said: we only build the Erlang packages for amd64.

It should be easy to build for i386 as well. I would love to add other architectures but that would require cross-compilation and I never did that so far with Debian packages. Thus, I have no idea about the amount of work.

[tianon]

Have you considered basing the rabbitmq image on erlang:21?

Yes! That image is significantly larger than the rabbitmq image, and I haven't had time to look into why. Even erlang:21-slim by itself is bigger than the current rabbitmq:latest image.

• rabbitmq:latest: ~125MB
• erlang:21: ~1.06GB
• erlang:21-slim: ~249MB

[gerhard]

@tianon Got it. Happy to help as soon as I come across this again, have too many things in flight to start a new thing. Leaving a reminder for next time 💡compile Erlang/OTP 21.0.x from source💡

@michaelklishin since rabbitmq:3.7.7 Docker image is already using Erlang/OTP 20.3.8.3, what are your thoughts on next steps?

[michaelklishin]

@gerhard I think that means we are all set for now. If our repo isn't suitable because we only support one architecture at the moment, that's fine. We can always revisit this in the future.

[tianon]

Looks like we get the privilege of revisiting this... 😬

We've been installing Erlang from buster into our stretch-based image, which has worked great, but now there's been a libssl transition which pulls in a newer libc (all via the erlang-crypto package), so that's impossible to continue.

The way I see it, we have a couple options:

1. base our image on buster officially

   • pros: trivially get plenty new enough Erlang, keep many architecture support
   • cons: it's "testing" and is not explicitly supported by the Debian security team, potentially too new of Erlang at some point

2. base our image on erlang:xxx-slim

   • pros: trivially pin to an explicit Erlang version, keep many architecture support
   • cons: our base image size will go up by 2x on both Debian and Alpine variants immediately (the current erlanx:xxx-slim and erlang:xxx-alpine are roughly 2x the size of the current rabbitmq:xxx and rabbitmq:xxx-alpine images)

3. keep stretch, use https://github.com/rabbitmq/erlang-debian-package

   • pros: explicitly officially supported Erlang version!
   • cons: lose almost all supported architectures

4. keep stretch, build Erlang from source ourselves? (possibly from the package source in https://github.com/rabbitmq/erlang-debian-package? appears to not have .dsc files on bintray, so reproducing the builds properly might be a little difficult)

   • pros: explicit Erlang version, keep many architecture support
   • cons: oh lordy the compile times 😱

If there are any options I've missed, I'm definitely open to further discussion -- the cons above really speak for themselves. 😞

[tianon]

(It would be great if whatever solution we end up with ends up aligning the Debian and Alpine variants on the exact same Erlang release, but I realize that's a bit of a "stretch" goal. 😅)

[michaelklishin]

https://github.com/rabbitmq/erlang-debian-package simply packages new releases because the Erlang community doesn't do a good job of getting builds of patch releases out quickly. It is orthogonal to what versions of Erlang RabbitMQ supports, officially or otherwise.

We can consider producing packages for more architectures. What architectures are you after @tianon?

Also, we can publish more things to make option 4 possible (even though I'd hate to see a yet another set of Erlang packages produced, the OTP team and Erlang Solutions should get their stuff together).

Lastly, using buster doesn't seem to be too aggressive to me as long as you control what Erlang version gets provisioned.

[michaelklishin]

@dumbbell FYI