openstack/kolla.git/docker/rabbitmq/Dockerfile.j2, branch stable/2025.2

Move repo enablement to respective rpm blocks

2025-10-02T08:37:07+00:00

Currently we are enabling repos irrespective of rpm/deb statement blocks and not failing in the method used if a repository is missing. Downside is - we might be producing one more layer, but it probably is a more logical approach. This is required for adding rpm support in repos.yaml that will also include failing on missing repositories. Change-Id: I5479c5c935760f00fe4cd307366f261deee3199f Signed-off-by: Michal Nasiadka

rabbitmq: Update to 4.1

2025-05-20T11:50:52+00:00

Change-Id: I4f852176918531ea19210961fd1b4fa63bc0ecca

Merge "rabbitmq: Bump to 4.0"

2025-04-11T08:35:39+00:00

rabbitmq: Bump to 4.0

2025-04-10T14:52:45+00:00

Change-Id: If15ba52acfd305aa9bbae382fe7429c11041e93f

Add mechanism for patching files in containers

2024-11-15T08:04:30+00:00

This patch adds a way to patch files in a Docker image built by Kolla. This is very useful for several reasons, specifically: - Custom modifications - The stable branch of some library has a fix but no pip package has been released - Eliminates the need to package your own pip packages - Eliminates the need to invent your own versioning to prevent upstream versioning - Eliminates the need to manage a pip server - In other words, it eliminates the need to get a wheel into the image and install it manually using any method not previously mentioned It is also highly desirable because, although Kolla can replace the source for a service with a custom URL for a tarball or its own Git repo, it cannot do this for dependencies pulled from pip. I would also like to point out that this is a feature with its own code path and works only if the user "inserts" a patch into the folder patches/docker-image/something.patch and creates an analogous series file for patch source code. Simply said, this code will never interfere with the upstream build process since this feature is not intended for use in upstream. It is rather meant for downstream users who know what they are doing. Now they just have an option to patch their images. Everything works on all layers of the Docker image and stores a report of applied patches which can then be seen in /etc. This mechanism is similar as debian patch quilt. Change-Id: I61d0790c5d4d070b7ea9e8c99c0a76ff5d22bf9d

Revert "Add support for checking incoming RabbitMQ version"

2024-08-28T11:05:50+00:00

This reverts commit 36a7cd053d5b13ecc9fad1866f244a733fdd58e5. Reason for revert: feature not needed anymore, see here: https://review.opendev.org/c/openstack/kolla-ansible/+/926146/comment/e593d721_7c48143b/ Change-Id: Ic0f9521c66240f13ff5b7fc94480dbbb76498339

Add support for checking incoming RabbitMQ version

2024-08-12T15:08:43+00:00

Will be used to check if the current RabbitMQ version is high enough before upgrading to the new one. Change-Id: Ie133d6efc2e4c00002b8f0724e0183eaab35d1c5

Move apt_prefs pins to respective images

2024-04-16T18:43:18+00:00

Change-Id: I9eb51e079fee1322bcaaf9d481cd7890aeb77696

Bump rabbitmq to 3.13

2024-03-11T15:11:54+00:00

Pinning Erlang to 26.2.* (max supported version as per [1]), so we don't break this in future when Erlang 26.3 becomes available. [1]: https://rabbitmq-website.pages.dev/docs/which-erlang Change-Id: I1fd03a67914386129d7b0bb9be6aca86982f98f3

rabbitmq: bump version to 3.12

2023-08-16T06:55:45+00:00

Erlang has been bumped to 26 as well. Change-Id: I5a6e90790d9c3c148e118fdf2ce6089e0a6a343e