We need these to debug various rabbitmq-related issues. Ephemeral debug
containers are not enabled on GKE Autopilot (not sure if GKE enables
this alpha feature at all), so we are doing this instead.
error: ephemeral containers are disabled for this cluster (error from server: "the server could not find the requested resource").
Backport to v3.9.x & v3.8.x if build passes
Pair @Gsantomaggio
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
Add a make target that helps finding out SHA256 for specific OTP
versions. Inline comments have all the context.
Pushing straight to master to find out if it works. If it does, will
back-port to v3.9.x & v3.8.x
cc @ansd
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
This is the best way of ensuring that everything works. RabbitMQ is not
just the core components, it's all the plugins that ship with it. While
we don't expect anyone to enable all plugins at the same time (for
example enabling all peer discovery plugins at the same time doesn't
make sense), we need to be minimally confident that everything works.
As we work on & QA various features in dev, this is the quickest way of
doing just that.
For example, today we were testing some Stream features with
@GSantomaggio and discovered that we needed to use a different image for
it, pivotalrabbitmq/rabbitmq-stream, because in the dev image we don't
enable the stream plugin by default. There is no reason why we would
need a different container image to test a core feature, that ships part
of RabbitMQ as a Tier 1 plugin. To be honest, I strongly believe that
everyone be looking at these specific images (otp-max & otp-max-1) which
bundle the majority of the RabbitMQ experience in a single artefact,
including OpenSSL & Erlang.
While I would normally push this straight into the main branch, I'm
doing it as a PR so that the following notice, and have the opportunity
to comment on this standalone:
- @michaelklishin
- @GSantomaggio
- @Zerpet
- @MirahImage
- @ansd
As next steps, after all checks pass, can someone from the above list
action the following please:
- merge into our main branch
- backport to v3.9.x
- deploy to lre-3-9
🙌
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
See https://github.com/docker-library/rabbitmq/pull/492
Co-authored-by: Michal Kuratczyk <mkuratczyk@vmware.com>
Ensure compilation and runtime Erlang are in sync
Bump to Ubuntu 20.04
docker-library/rabbitmq also uses Ubuntu 20.04
Certain keyservers fail seasonally & intermittently - every few months
one stops working reliabley - so then we alternate between them. Last
time we had this problem, pgpkeys.eu was failing, and now pgpkeys.uk
seems to be failing and resulting in flaky builds:
https://github.com/rabbitmq/rabbitmq-server/runs/2663558141?check_suite_focus=true
Trying pgpkeys.eu now, and preparing to go to the Ubuntu one next if
this one proves to not be as reliable as we would like it to be.
As a different approach, I am wondering if we should store these PGP
keys somewhere instead? WDYT @dumbbell?
Thanks @pjk25 for flagging this!
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
in addition to tagging the docker image with the Git commit SHA.
This enables the cluster-operator to run system-tests against latest
rabbitmq-server master branch which allows us to fix any breaking
changes early and to test unreleased features such as rabbitmq_stream
plugin.
Before this, someone would need to run the package-generic-unix and
docker-image make targets in order to produce a container image. This
wouldn't always work: more than one archive in the PACKAGES dir, VERSION
& RABBITMQ_VERSION had to be specified, + characters in VERSION. It also
required me to have Docker running, which I am reluctant to leave
running on macOS because it uses CPU even when idle, and starting it
every time that I wanted an ad-hoc container image implied waiting a few
minutes, and then waiting another 15 minutes for the container image to
be produced and published to hub.docker.com.
This commit delegates all the above to GitHub Actions. The best part is
that it happens asynchronously - every commit triggers it - and a
container image for that commit will appear on hub.docker.com within ~15
minutes. In other words, anyone can test any commit in their container
runtime within 20 minutes, without needing to lift a finger. No Docker,
no make targets, just reference the new tag (matches the git sha) and
off you go. It's the beginning of something better, for sure.
Did some cleanup in the Dockerfile part of this. Dropped
RABBITMQ_VERSION build arg, env & commented steps. This is cruft that we
no longer need or even use.
Also fixed VERSION in push target and broken the dependency on dist so
that they can be run independently.
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
The previous approach assumed `make package-generic-unix` had only been run once.
This borrows a snippet from rabbitmq-components.mk to select the `current` version
for the docker build by default.
Also, don't depend on package-generic-unix, otherwise that will be
re-built every time we want to build the docker image, which is
unnecessary. It will fail now if a generic-unix doesn't exist, but
that's OK.
Signed-off-by: Gerhard Lazu <gerhard@lazu.co.uk>
Like other packaging files, they should not be part of RabbitMQ itself.
One day, they will probably be moved to a dedicated repository, like
other packaging files.
Michal Kuratczyk
GitHub
Gerhard Lazu
pjk25
Philip Kuryloski
David Ansari
Loïc Hoguin
Jean-Sébastien Pédron