<feed xmlns='http://www.w3.org/2005/Atom'>
<title>openstack/kolla.git/docker/kerbside/kerbside-base, branch master</title>
<subtitle>Unnamed repository; edit this file 'description' to name the repository.
</subtitle>
<id>https://git.platform-os.org/openstack/kolla.git/atom?h=master</id>
<link rel='self' href='https://git.platform-os.org/openstack/kolla.git/atom?h=master'/>
<link rel='alternate' type='text/html' href='https://git.platform-os.org/openstack/kolla.git/'/>
<updated>2026-07-06T19:59:40+00:00</updated>
<entry>
<title>Migrate to pyproject.toml</title>
<updated>2026-07-06T19:59:40+00:00</updated>
<author>
<name>Michal Nasiadka</name>
<email>mnasiadka@gmail.com</email>
</author>
<published>2026-07-06T13:26:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.platform-os.org/openstack/kolla.git/commit/?id=db35ac8d793506bc43b62e7e39d27a75de1043ed'/>
<id>urn:sha1:db35ac8d793506bc43b62e7e39d27a75de1043ed</id>
<content type='text'>
[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 &lt;mnasiadka@gmail.com&gt;
</content>
</entry>
<entry>
<title>kolla-build: fix build-date LABEL invalidating Docker layer cache</title>
<updated>2026-06-24T13:00:26+00:00</updated>
<author>
<name>Michal Nasiadka</name>
<email>mnasiadka@gmail.com</email>
</author>
<published>2026-06-18T15:16:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.platform-os.org/openstack/kolla.git/commit/?id=a1a3fdc1b54baf62f234ddc9dac4906e30eb5d11'/>
<id>urn:sha1:a1a3fdc1b54baf62f234ddc9dac4906e30eb5d11</id>
<content type='text'>
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 &lt;mnasiadka@gmail.com&gt;
</content>
</entry>
<entry>
<title>Implement container image build for kerbside.</title>
<updated>2026-06-03T03:10:47+00:00</updated>
<author>
<name>Michael Still</name>
<email>mikal@stillhq.com</email>
</author>
<published>2026-06-03T03:10:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.platform-os.org/openstack/kolla.git/commit/?id=118541d5b3de5290d64a1e137d7bfb59afd8db4e'/>
<id>urn:sha1:118541d5b3de5290d64a1e137d7bfb59afd8db4e</id>
<content type='text'>
This change adds images for Kerbside. Kerbside is a SPICE protocol
native proxy used to expose the new spice-direct console type provided
by Openstack Compute. This allows high fidelity virtual desktop
experiences without requiring transcoding of the console into HTML5
in Horizon, or allowing users direct access to the console ports on
your hypervisors.

Sadly, Red Hat chose to remove SPICE support from qemu in RHEL9, and
Rocky Linux has followed along. You therefore _must_ run the Debian or
Ubuntu container images if you wish to use the ``spice-direct``
console type.

Architecturally Kerbside has two components -- an API service which
turns console access URLs from Nova into URLs to ``.vv`` files, and
a proxy service which actually proxies the SPICE traffic. These are
handled as separate container images here because they're quite
different. One is a WSGI REST API, and the other is a daemon. It is
also likely that deployers would choose to host these on different
machines.

Finally, the proxy service needs to be special cased in load
balancing because it strongly expects to terminate TLS itself. The
haproxy is therefore configured as a layer 4 proxy in this case.

Depends-On: https://review.opendev.org/c/openstack/kolla/+/991249
Change-Id: If60a70745462e1360cfadaab1a5a8d75b7fdeb21
Partial-Bug: #2131793 (spice-direct consoles)
Signed-off-by: Michael Still &lt;mikal@stillhq.com&gt;
</content>
</entry>
</feed>
