| Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
[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>
|
|
|
|
|
|
|
|
|
|
Change-Id: I74a6d05007488b69fa040c40d01a07afae369794
Needed-By: https://review.opendev.org/c/openstack/kolla-ansible/+/989850
Signed-off-by: Michal Arbet <michal.arbet@ultimum.io>
|
|
The removed Python octal notation test is already covered by
test_handle_permissions_accepts_valid_permission_notations, which
includes 0o2775.
Change-Id: Ia25d10a6ff3608e2a38d1a88bf229fe3f96d19ee
Signed-off-by: Michal Arbet <michal.arbet@ultimum.io>
|
|
|
|
kolla_set_configs currently fails to parse permissions
such as 2775 because only legacy values like 0755 are
converted to Python octal notation.
Accept standard UNIX permission notation for
permissions with special mode bits such as SGID, SUID,
and sticky bit.
Change-Id: I5937a17b0d70f9c1db4b2617854d0180c37fe2c0
Closes-Bug: #2154269
Needed-By: https://review.opendev.org/c/openstack/kolla-ansible/+/989850
Signed-off-by: Michal Arbet <michal.arbet@ultimum.io>
|
|
|
|
The nova-libvirt-spice image is a kerbside fork of the upstream
nova-libvirt image, and is what kolla-ansible deploys for the
nova_libvirt container when kerbside is enabled. Mirror the virtlogd
changes made to the upstream image: install libvirt-daemon-log where
it is a separate package, and add the start script which runs
virtlogd as a sidecar of libvirtd so that nova instance console logs
are rotated.
Change-Id: Ifdcd3ae34e62fc484d1a25ef6f6c68c467745fda
Depends-On: https://review.opendev.org/c/openstack/kolla/+/993065
Signed-off-by: Michael Still <mikal@stillhq.com>
|
|
RHEL9 dropped SPICE support from qemu-kvm, and Rocky Linux followed
suit. Up until now the documented guidance has been to use the Debian
or Ubuntu container images if you want to serve the ``spice-direct``
console type, because the stock Rocky nova-libvirt image will simply
fail to start any SPICE-enabled instance.
This change adds a second version of the nova-libvirt container image
called nova-libvirt-spice. It is always built, but is identical for
all supported container base distributions except for Rocky Linux.
In the Rocky Linux case, this container adds the community
maintained ligenix/enterprise-qemu-spice COPR repository that provides
a rebuild of ``qemu-kvm`` with SPICE support re-enabled for both
EPEL 9 and EPEL 10.
Which nova-libvirt container should be used in a given deployment is
delegated to logic in kolla-ansible, based on the deployer's settings
in globals.yml.
The COPR is a third-party rebuild with no vendor support contract.
The release note and support matrix are updated to describe the
opt-in path and call this caveat out explicitly. The earlier
"you must use Debian or Ubuntu" wording in the support matrix is
softened here, rather than by retroactively editing the kerbside
container-build patch that introduced it, so that this feature can
land (or not land) independently of the earlier change.
Partial-Bug: #2131793 (spice-direct consoles)
Prompt: I am interested in seeing how we would go about using
https://copr.fedorainfracloud.org/coprs/ligenix/enterprise-qemu-spice/
to add SPICE support back to the Kolla build Rocky Linux containers
as a new patch in the kolla/ORDER list. Could you please investigate
options here?
Assisted-By: Claude Code
Co-Authored-By: Claude Opus 4.7 (1M context, medium effort) <noreply@anthropic.com>
Change-Id: I410b87b7f8cdd541c48d9a749b3fea634a5f4e6c
Signed-off-by: Michael Still <mikal@stillhq.com>
|
|
From the experience we have made so far, a lot of AI based contributions
tend to cause more work rather than they bring benefit. So we caution
people to avoid this when possible.
The wording of the policy was adapted from the Zuul project [0].
[0] https://review.opendev.org/c/zuul/zuul/+/993998
Co-Authored-By: James E. Blair <jim@acmegating.com>
Signed-off-by: Dr. Jens Harbott <harbott@osism.tech>
Change-Id: I5fcd5bea33c4f4c87b6f6cf0a96514e8d2da3af3
|
|
It seems that the original maintainer lost write access to
google/mtail repository long time ago, and we still ship
versions from 2024.
[1]: https://github.com/google/mtail/issues/929
Change-Id: I41c5d0649eb38348ccda413b7d6537830cd82bec
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
|
The reset_userinfo tar filter used when creating plugins and
additions archives normalized uid/gid but left mtime untouched.
Since archives are created after set_time() has already run, and
the default working directory is a fresh temp dir per invocation,
the embedded directory mtime was always the current time.
Docker computes a content checksum for ADD instructions, so a
different mtime in the tar produced a different checksum on every
run.
Fix by setting tarinfo.mtime = 0 in both reset_userinfo filters and
calling os.utime(arc_path, (0, 0)) on the archive file after
creation, making the archives binary-identical across runs for the
same content.
Change-Id: I205dab2c4a74fb9e3cb15c421d5c025849f5632a
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
|
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>
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 4cdf881631eb0a671b9f70d5afefa6ead1949118.
Reason for revert: It's fixed in Horizon
Change-Id: If7e6ad7114c69de2435732a45f7a86a7b9bfeca1
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
|
This release fixes multiple security issues [1].
[1] https://github.com/prometheus/prometheus/releases/tag/v3.5.4
Change-Id: I1ec8f15e14360422aa316779bd19195fd1f4f7a1
Signed-off-by: Pierre Riteau <pierre@stackhpc.com>
|
|
This is no longer required
Depends-On: https://review.opendev.org/c/openstack/kolla-ansible/+/993932
Change-Id: I20a2ff0a97b9fad86b6103ec488a39e42cdba091
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
|
|
|
Add --buildkit flag to use docker buildx build instead of the docker-py
SDK. An optional --buildkit-builder selects a named buildx builder
instance, enabling docker-container or remote drivers for multi-arch
builds.
--buildkit and --squash are mutually exclusive and rejected at startup.
PushTask is skipped when buildkit is active; push is handled inline.
Set buildkit as the new default.
Change-Id: Idbf1d1bdc091bb84721f8006c2b916731b999859
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
|
Following the PTG agreement, this commit extends the container
configuration engine (set_configs.py) to support YAML format while
maintaining backward compatibility with JSON.
- Integrated 'yaml' library as a universal parser for both JSON
and YAML formats (YAML is a superset of JSON)
- Updated 'load_config' to search for 'config.json', 'config.yaml'
- Added 'python3-yaml' (Debian) and 'python3-pyyaml' (RHEL) as
required base packages in Dockerfile.j2
This change improves configuration readability and allows for
easier maintenance while ensuring no breakage for existing
JSON-based deployments.
Change-Id: Icfb52b8f94e1036d5952b160c5921348d1427fda
Signed-off-by: Piotr Milewski <vurmil@gmail.com>
|
|
OpenDev does not have enough aarch64 node capacity at this point and the
backlog has grown to several days, which is also blocking non-arm64
periodic jobs. This means new Kolla images are not published to Quay.io.
Switch arm64 publish jobs to periodic-weekly so they stop blocking other
publish jobs.
Change-Id: Iffa7e2908c1beb083a9535e7328dcab687248c06
Signed-off-by: Pierre Riteau <pierre@stackhpc.com>
|
|
Change-Id: I7513f1ab627aa5137e16777ca6bee600e14a00e9
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
|
|
|
Due to implementation choices in qemu and libvirt, standard log
rotate does not work on these console files, and instead the usual
approach is to have libvirt's virtlogd rotate the contents of the
console log file when it gets a bit big. OpenStack Compute knows
how to read data from more than one rotated console log file if
required to service a REST API request.
OpenStack Kolla and Kolla-Ansible deploy OpenStack components in
docker or podman containers. An error in the startup configuration
for the nova_libvirt container results in the libvirt virtlogd
daemon not being run, which results in this console log rotation
not occurring.
This opens up the risk of a disk usage denial of service attack
on a hypervisor. The console log is stored on the same filesystem
as ephemeral disks, and OpenStack Nova will take a hypervisor out
of service if disk space becomes constrained. There is some
protection from the instance console not being able to write data
particularly quickly, but it is definitely still possible to fill
the hypervisor file system -- especially if multiple instances are used.
This misconfiguration appears to exist in all versions of
Kolla / Kolla-Ansible as best as I can tell.
Partial-Bug: 2155214
Change-Id: Ib62191e3022e5bcff781c12f662c9800fb210eb9
Signed-off-by: Michael Still <mikal@stillhq.com>
|
|
|
|
|
|
Change-Id: I9619583ccd14c56389f375c0d356a9ec2eebdcfa
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
|
Switch from jinja2.Environment to
jinja2.sandbox.SandboxedEnvironment to block Server-Side Template
Injection attacks.
Closes-Bug: #2146056
Change-Id: Iecd1d8dcf99007e3339120961c7c1d0ca12f83d8
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
|
This reverts commit d55c024327531bf255d96021dfbc8e84a364f9c0.
Reason for revert: openstack.cloud collection 2.6.0 is out
Change-Id: I121ac28929effb26a56007b90abf08bee7e29539
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
|
4.15.0 is out and it broke openstack.cloud modules
Change-Id: I8e0f7663339964ca4418e38314adcb0487833464
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
|
Needed-By: https://review.opendev.org/c/openstack/kolla-ansible/+/992020
Related-Bug: #2155865
Change-Id: I1c67f6b0f4780b7caf83ccf95a20861d9fefe20b
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
|
|
|
|
|
|
|
This reverts the OPENSTACK_RELEASE bump from kolla commit 352b7fce.
The stable/2026.1 branch is now active, so the late-cycle pin to
'2026.1' is stale and needs to be reverted back to 'master' --
mirroring the same housekeeping pattern as the 2025.1->master
revert (87678d014, 2025-05) and the 2025.2->master revert
(c30e4e524, 2025-12).
I specifically found this because Nova master commit 770580bb bumped
oslo.privsep in requirements.txt from >=2.6.2 to >=3.11.0. With
OPENSTACK_RELEASE = '2026.1', openstack_branch resolves to
stable-2026.1 and openstack-base pulls
requirements-stable-2026.1.tar.gz, which still pins
oslo.privsep===3.10.1. The resulting ResolutionImpossible causes
image builds to fail.
Change-Id: I7d156af2fa9677cd4921f518ac1c6ecf7acde9ce
Signed-off-by: Michael Still <mikal@stillhq.com>
|
|
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 <mikal@stillhq.com>
|
|
|
|
And remove the redundant comment and repo enablement in keystone
container.
Change-Id: I3a64b13fcaef62c73cccc9c478e7392efc8ee554
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|
|
|
|
|
|
Change-Id: I8fca57c43b032ec11e1fb95294ed85bf5876730e
Signed-off-by: Michal Nasiadka <mnasiadka@gmail.com>
|