From ea083b1be24fc6938389e996eff1e7e7afb610bc Mon Sep 17 00:00:00 2001 From: Michal Nasiadka Date: Mon, 24 Aug 2026 15:02:29 +0200 Subject: [PATCH 1/3] CI: Fix setup_gate.sh It seems due to new pbr and old pip we're seeing issues related to pbr being unable to import tomli (to scan pyproject.toml). Needed-by: https://review.opendev.org/c/openstack/kolla/+/1002078 Change-Id: Ida5906f837dbee93e8cbf72ff0633c10cdd233a6 Signed-off-by: Michal Nasiadka Signed-off-by: Bartosz Bezak --- tests/setup_gate.sh | 1 + 1 file changed, 1 insertion(+) diff --git a/tests/setup_gate.sh b/tests/setup_gate.sh index 81618711f6..b447e24946 100755 --- a/tests/setup_gate.sh +++ b/tests/setup_gate.sh @@ -20,6 +20,7 @@ function prepare_images { python3 -m venv ~/kolla-venv source ~/kolla-venv/bin/activate + pip3 install -U pip if [[ "$CONTAINER_ENGINE" == "docker" ]]; then pip install "${KOLLA_SRC_DIR}" "docker" else From 45264f26b0c3ff7db19c30a0e11bd97c456fbebc Mon Sep 17 00:00:00 2001 From: Bartosz Bezak Date: Tue, 25 Aug 2026 13:53:00 +0200 Subject: [PATCH 2/3] [2025.1-only] CI: Build valkey gate images Since I613d471e5f1e6d563d3853761d8432cba60f3c4c the octavia, ovn, cephadm and nfv scenarios enable valkey, but scenario_images_extra still only listed redis, so valkey images were never built and the pull failed with a 404. cephadm and nfv keep redis - on RL9 they still deploy it, and kolla-ansible-rocky9-cephadm runs the redis to valkey migration Change-Id: Ibf437f8951a0737a2bd0a246c056c94c4860143d Signed-off-by: Bartosz Bezak --- zuul.d/base.yaml | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/zuul.d/base.yaml b/zuul.d/base.yaml index 86fa3bf0e0..40d7aa942a 100644 --- a/zuul.d/base.yaml +++ b/zuul.d/base.yaml @@ -200,6 +200,7 @@ scenario_images_extra: - ^cinder - ^redis + - ^valkey - job: name: kolla-ansible-magnum-base @@ -227,7 +228,7 @@ vars: scenario: octavia scenario_images_extra: - - ^redis + - ^valkey - ^octavia - job: @@ -279,6 +280,7 @@ - ^tacker - ^mistral - ^redis + - ^valkey - ^barbican - job: @@ -307,7 +309,7 @@ vars: scenario: ovn scenario_images_extra: - - ^redis + - ^valkey - ^octavia - ^ovn From 010c083b96519a8c52da16a636e76436125d8d92 Mon Sep 17 00:00:00 2001 From: Bartosz Bezak Date: Tue, 25 Aug 2026 10:24:42 +0200 Subject: [PATCH 3/3] mariadb: Back up from the local database instance Mariabackup copies the data directory of mariadb_backup_host but connected through the load balancer, so backup_replica.sh could redirect it to another Galera member. The backup lock then applied to the wrong node, leaving the copied files unquiesced. Connect to api_interface_address and mariadb_port instead, and always use the local backup script. MariaDB 10.11.19 and 11.4.13 no longer tolerate the mismatch. mariadb_backup_target now has no effect, and full backups are named mysqlbackup-.qp.xbc.xbs.gz, as the restore docs describe. Closes-Bug: #2165011 Related-Bug: #2125124 Change-Id: I33ebd36c728ff50df8ebf13fc5af9882a0e71d23 Signed-off-by: Bartosz Bezak (cherry picked from commit f1f2702bbe812e285f0766a5787159ba92fdce8b) --- ansible/roles/mariadb/tasks/backup.yml | 4 +--- ansible/roles/mariadb/templates/backup.my.cnf.j2 | 4 ++-- ...-backup-connect-locally-9f4c2d1e7b3a0c65.yaml | 16 ++++++++++++++++ 3 files changed, 19 insertions(+), 5 deletions(-) create mode 100644 releasenotes/notes/mariadb-backup-connect-locally-9f4c2d1e7b3a0c65.yaml diff --git a/ansible/roles/mariadb/tasks/backup.yml b/ansible/roles/mariadb/tasks/backup.yml index 0ddd8521d2..e92c64d36e 100644 --- a/ansible/roles/mariadb/tasks/backup.yml +++ b/ansible/roles/mariadb/tasks/backup.yml @@ -10,12 +10,10 @@ register: container_facts - name: Taking {{ mariadb_backup_type }} database backup via Mariabackup - vars: - cmd: "{{ 'kolla_mariadb_backup.sh' if mariadb_backup_target == 'active' else 'kolla_mariadb_backup_replica.sh' }}" become: true kolla_container: action: "start_container" - command: "bash -c 'sudo -E kolla_set_configs && /usr/local/bin/{{ cmd }}'" + command: "bash -c 'sudo -E kolla_set_configs && /usr/local/bin/kolla_mariadb_backup.sh'" common_options: "{{ docker_common_options }}" detach: False # NOTE(mgoddard): Try to use the same image as the MariaDB server container diff --git a/ansible/roles/mariadb/templates/backup.my.cnf.j2 b/ansible/roles/mariadb/templates/backup.my.cnf.j2 index 0620e046ab..8d1ae25933 100644 --- a/ansible/roles/mariadb/templates/backup.my.cnf.j2 +++ b/ansible/roles/mariadb/templates/backup.my.cnf.j2 @@ -2,5 +2,5 @@ default-character-set=utf8 user={{ mariadb_backup_database_user }} password={{ mariadb_backup_database_password }} -host={{ database_address }} -port={{ database_port }} +host={{ api_interface_address }} +port={{ mariadb_port }} diff --git a/releasenotes/notes/mariadb-backup-connect-locally-9f4c2d1e7b3a0c65.yaml b/releasenotes/notes/mariadb-backup-connect-locally-9f4c2d1e7b3a0c65.yaml new file mode 100644 index 0000000000..6b54520d47 --- /dev/null +++ b/releasenotes/notes/mariadb-backup-connect-locally-9f4c2d1e7b3a0c65.yaml @@ -0,0 +1,16 @@ +--- +fixes: + - | + Fixes MariaDB backups failing since MariaDB 10.11.19 and 11.4.13. + Mariabackup copied the data directory of ``mariadb_backup_host`` but + connected through the load balancer, which could route it to a different + Galera member. The backup lock then applied to the wrong node. It now + connects to the MariaDB instance on the host it backs up. +upgrade: + - | + ``mariadb_backup_target`` no longer has any effect. Backups are always + taken from ``mariadb_backup_host``. + - | + Full backups are now named ``mysqlbackup-.qp.xbc.xbs.gz`` and + incrementals ``incremental--mysqlbackup-.qp.xbc.xbs.gz``, + matching the restore documentation. Existing backups remain restorable.