Unnamed repository; edit this file 'description' to name the repository. https://git.platform-os.org/openstack/kolla.git/atom?h=master 2026-07-06T19:59:40+00:00 2026-07-06T19:59:40+00:00 Michal Nasiadka mnasiadka@gmail.com 2026-07-06T13:26:00+00:00 urn:sha1:db35ac8d793506bc43b62e7e39d27a75de1043ed [tool.setuptools.data-files] does not support recursive directory installation. The old setup.cfg [files] worked because PBR's FilesConfig.expand_globs() used os.walk() to expand docker/*, but this hook is not triggered by the pbr.build PEP-517 backend. Move docker/ into kolla/ and use [tool.setuptools.package-data] instead. Update kolla_worker._get_images_dir() to check the kolla package directory first so both editable and regular installs work. Change-Id: I4fc452c03740ef22ebbb4e8d0d86c4f4783e2d09 Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com> 2026-06-24T13:00:26+00:00 Michal Nasiadka mnasiadka@gmail.com 2026-06-18T15:16:08+00:00 urn:sha1:a1a3fdc1b54baf62f234ddc9dac4906e30eb5d11 The build-date label was rendered into a LABEL instruction on line 3 of every Dockerfile template, immediately after FROM. Because Docker invalidates the cache for a changed instruction and all subsequent layers, a date change caused a full rebuild of every image on each new calendar day, even when nothing else had changed. Fix this by removing build-date from the Dockerfile templates and applying it as a --label argument at build time via image.labels. Labels passed on the build command line are not part of the Dockerfile cache key, so the date is still recorded in the image metadata without affecting layer caching. Change-Id: I8ef0d85bab1a999a4d09f7cbf0c088ca00fdcf77 Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com> 2024-11-15T08:04:30+00:00 Michal Arbet michal.arbet@ultimum.io 2022-02-15T12:50:59+00:00 urn:sha1:11f65c6c1d3bfd6a12f8e71d778d46d635010449 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 2024-02-26T12:04:19+00:00 Michal Nasiadka mnasiadka@gmail.com 2024-02-26T11:58:43+00:00 urn:sha1:66e27b3b0a60a5aa0122228210329889d914487f It does not exist in repos.yaml since [1]. [1]: Id585c7744ba130ad1dfc28138fb0f9e6eeae771d Change-Id: Ic74eba44fc6e5508976de24cf20a5039f3292731 2022-04-09T15:44:26+00:00 Marcin Juszkiewicz marcin.juszkiewicz+kolla@linaro.org 2022-04-01T11:41:14+00:00 urn:sha1:1749da2fbf6b395b1a2cd77f349e0bea5d2f4a5e Big patch drops all mentions of binary images support. Suggestions are welcome how to split it into parts or handle better. Change-Id: I5d5a46c6ce7734ceb8b844e17b43e359d7cac6e3 2021-03-23T21:08:11+00:00 Marcin Juszkiewicz marcin@juszkiewicz.com.pl 2021-03-23T21:05:10+00:00 urn:sha1:fb61ba7daccfe8b13eff3b773cc09d69aa0039e7 There are several images installing 'python3-libvirt' package. Which for Debian reside in 'libvirt' repo. So let's enable it where needed. Change-Id: I1c91d27f2578f5ca7c83c4747725b1d9371880b0 2020-04-15T09:32:06+00:00 Marcin Juszkiewicz marcin.juszkiewicz@linaro.org 2020-03-09T16:44:54+00:00 urn:sha1:53443c5c712f4ec23b859105e94bcd90abc27762 With the move to RHEL/CentOS 8 we no longer have Python 2 in our images so there is no need for checking which Python version (2.x or 3.x) is used inside of containers. We also no longer have to support yum as a value for distro_package_manager. Partially-Implements: blueprint centos-rhel-8 Change-Id: Ie45cf3465fedddbde7856961527421883ba3d5c9 2020-03-01T17:25:58+00:00 Christian Berendt berendt@betacloud-solutions.de 2020-02-19T21:39:33+00:00 urn:sha1:861f55fbfd7558d56008e6275b0c6f5993346b95 Change-Id: I9692dda817ef134d647247431565e1b58cf9da41 2020-01-29T11:41:38+00:00 Mark Goddard mark@stackhpc.com 2019-12-17T13:01:42+00:00 urn:sha1:4b4e26262b9e03190c639481fb60a8f4f92c532a * Some further changes for python2 vs python3 packages * Allow rabbitmq 3.7.*, since a newer erlang is available * Switch from qemu-img-ev to qemu-img on CentOS 8 * bridge-utils no longer available on CentOS 8 * libvirt-daemon-driver-lxc no longer available on CentOS 8 * Mark some more images buildable for CentOS 8 Change-Id: Iaf5b68ff6d944ae730ca0b1d5832172c106a6c08 Partially-Implements: blueprint centos-rhel-8 Partially-Implements: blueprint centos-rhel-python-3 2019-06-07T08:29:09+00:00 Zuul zuul@review.opendev.org 2019-06-07T08:29:09+00:00 urn:sha1:17ce7d4de63273a0beca972b5f3cea1a0b62c928